Re: Proposal to remove three datatracker pages (https://datatracker.ietf.org/iesg/ann/ind/, /new, and /prev
Hi, On 2011-12-16 09:20, Robert Sparks wrote: > There are three pages exposed at the datatracker that have become stale > or are producing erroneous information. > https://datatracker.ietf.org/iesg/ann/ind/ "IESG Statements on Independent Submissions" This is in theory very useful information. I haven't needed it recently, but I've certainly used it in the past. How else will people find it? Searching the mail archive (or the IESG minutes) is really not very convenient. Please check with the ISE before scrapping this. It would be fine if these announcements were collated on the RFC Editor site, but I don't see them at http://www.rfc-editor.org/indsubs.html > https://datatracker.ietf.org/iesg/ann/new/ > https://datatracker.ietf.org/iesg/ann/prev/ > > Has anyone been using those links? Again, not recently, but it's still a lot more convenient than searching the mail archive or the minutes. I don't clearly remember, but I think these pages were created in response to complaints about lack of IESG transparency and the inconvenience of searching email archives. So I'd be a bit sorry to see them go. OTOH they obviously need to work properly if they're kept, and they would be much more useful if they included the full draft name as well as the title. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Proposal to remove three datatracker pages (https://datatracker.ietf.org/iesg/ann/ind/, /new, and /prev
There are three pages exposed at the datatracker that have become stale or are producing erroneous information. https://datatracker.ietf.org/iesg/ann/ind/ https://datatracker.ietf.org/iesg/ann/new/ https://datatracker.ietf.org/iesg/ann/prev/ Has anyone been using those links? The first link, in particular has not been updated to reflect RFC5742, and is currently showing an incomplete set. All of the information on those pages is available in other locations (at the very least at <http://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html>. Unless someone has been relying on these links, I propose removing them. RjS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
The new SSL certificates have been received, and installed. Regards, Alexa On Sep 1, 2011, at 8:57 AM, SM wrote: At 03:50 26-08-2011, Scott Schmit wrote: Mistakes happen. Hopefully lessons are learned so that they don't get repeated. It has been a week since the problem was reported and the SSL certificate is still showing up as expired. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com <http://www.amsl.com/> ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On Thu, Sep 1, 2011 at 11:57 AM, SM wrote: > At 03:50 26-08-2011, Scott Schmit wrote: > >> Mistakes happen. Hopefully lessons are learned so that they don't get >> repeated. >> > > It has been a week since the problem was reported and the SSL certificate > is still showing up as expired. > > This is definitely being worked on and the appropriate people are definitely aware of it. I will try and get a status report. Regards Marshall > Regards, > -sm > __**_____ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/**listinfo/ietf<https://www.ietf.org/mailman/listinfo/ietf> > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 2 September 2011 01:04, Adam Novak wrote: > Who is the appropriate net monkey to handle this? abuse@ietf works to create a ticket, but IIRC somebody did that already using a similar address. JFTR, I'd prefer it if the IAOC doesn't waste money for a new certificate, and the IETF simply starts its own CA. Still dogfood + eating, but cheaper and much more fun. Don't forget to delete DigiNotar everywhere [*]. -Frank *: http://www.h-online.com/security/news/item/CA-hack-more-bogus-certificates-1334651.html> ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
Who is the appropriate net monkey to handle this? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
At 03:50 26-08-2011, Scott Schmit wrote: Mistakes happen. Hopefully lessons are learned so that they don't get repeated. It has been a week since the problem was reported and the SSL certificate is still showing up as expired. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
Original Message - From: "Hector Santos" To: "Adam Novak" Cc: "IETF Discussion" Sent: Friday, August 26, 2011 8:49 PM Subject: Re: https > I see, so as long as its not revoked, if compromised, you are hosed > until it expires. > > I wonder if OCSP (Online Certificate Status Protocol) can help > addresses this? Hector Back in 2008, some people could not access the IETF website using TLS because of OCSP; I think that the URI for the OCSP site for the certificate was unavailable, at least for some parts of the world. Another potential vector for failure. Tom Petch >Expired or not, it can still be revoked with dynamic > checking as long as the browser as OCSP enabled. So I guess its a > matter of reporting the theft as soon as it is discovered. > > > Adam Novak wrote: > > On Fri, Aug 26, 2011 at 1:13 PM, Hector Santos wrote: > >> Makes you wonder. Why is the concept of expiration required? �Did the IETF > >> expire, die? �Did its value as an Organization go down and only valid on a > >> year to year basis? > > > > As I understand it, expiration is supposed to solve the problem of > > someone getting their hands on your old certificates and impersonating > > you. In order to impersonate you, not only do they have to get into > > your system, they have to have done it in the last year or so. > > > > It also keeps certificates for domains from outliving domain > > registrations for too long. If you don't have the domain when you go > > to renew the certificate, the CA shouldn't renew it. > > > > I guess it also keeps revocation lists short. You only have to > > remember that a certain certificate was compromised until it expires, > > instead of forever. > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > > > -- > Sincerely > > Hector Santos > http://www.santronics.com > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: authenticated archives, was https
On Aug 27, 2011, at 7:30 PM, Hector Santos wrote: > Keith Moore wrote: >> On Aug 27, 2011, at 10:31 AM, John Levine wrote: >>> TLS for session privacy is nice, but I find negligible value in a >>> little lock icon in my browser that means only that one of the several >>> dozen cert issuers configured into my browser, most of whom I've never >>> heard of, and many of whom aren't even the organization in the cert >>> name, signed something. >> +1. IMO browser vendors have made TLS nearly useless for web browsing by >> including so many default CAs; some with dubious integrity, and a few with a >> demonstrated lack of integrity. > > Interesting viewpoint. Are you advocating for a monopoly or oligopoly > centralization? no, replacing one flawed model for another won't help. the root problem is that users are being expected to extend trust to whatever set of CAs the browser vendors find "convenient", and browser vendors can be influenced/coerced in these choices by various means. but it's not as if users are in a better position to decide which CAs are trustworthy. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: authenticated archives, was https
Keith Moore wrote: On Aug 27, 2011, at 10:31 AM, John Levine wrote: TLS for session privacy is nice, but I find negligible value in a little lock icon in my browser that means only that one of the several dozen cert issuers configured into my browser, most of whom I've never heard of, and many of whom aren't even the organization in the cert name, signed something. +1. IMO browser vendors have made TLS nearly useless for web browsing by including so many default CAs; some with dubious integrity, and a few with a demonstrated lack of integrity. Interesting viewpoint. Are you advocating for a monopoly or oligopoly centralization? I having read anyone mention OCSP (Online Certificate Status Protocol) which use to be off by default, but appears to be enabled by default now by updated browsers. It was a painful to solve a customer problem when most browser work fine with a brand new certificate but failed when newer browser had OCSP enabled. Some miscommunication issue on the type of certificate brought and wildcard domains. The CA has revoked it but only via OSCP was it detectable. The ongoing direction of dynamic tracking of anything and anyone continues to amaze me. -- Sincerely Hector Santos http://www.santronics.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
Try it with Chrome and it makes you feel like the world blew up, I suppose intentionally as a fail-safe for the user-sake. Doug Barton wrote: Joel, I don't know what "It doesn't" is supposed to mean, but visiting https://www.ietf.org/* today with firefox it is still reporting that the certificate expired yesterday. Given the volume of discussion about the topic starting yesterday when the problem started one could easily make a case for "it's still broken" being a significant "issue." cc'ing the address listed as "Report Website Errors" on the home page. Doug On 08/26/2011 07:44, Joel jaeggli wrote: It doesn't... http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html On 8/26/11 00:18 , t.petch wrote: Why does the IETF website consider it necessary to use TLS to access the mailing list archives, when they all appeared without it, or any other security, in the first place? Besides all the usual hassle of TLS, today the certificate is reported by IE as expired, which sort of sums it up. Tom Petch _______ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf _______ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Sincerely Hector Santos http://www.santronics.com _______ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
I see, so as long as its not revoked, if compromised, you are hosed until it expires. I wonder if OCSP (Online Certificate Status Protocol) can help addresses this? Expired or not, it can still be revoked with dynamic checking as long as the browser as OCSP enabled. So I guess its a matter of reporting the theft as soon as it is discovered. Adam Novak wrote: On Fri, Aug 26, 2011 at 1:13 PM, Hector Santos wrote: Makes you wonder. Why is the concept of expiration required? �Did the IETF expire, die? �Did its value as an Organization go down and only valid on a year to year basis? As I understand it, expiration is supposed to solve the problem of someone getting their hands on your old certificates and impersonating you. In order to impersonate you, not only do they have to get into your system, they have to have done it in the last year or so. It also keeps certificates for domains from outliving domain registrations for too long. If you don't have the domain when you go to renew the certificate, the CA shouldn't renew it. I guess it also keeps revocation lists short. You only have to remember that a certain certificate was compromised until it expires, instead of forever. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Sincerely Hector Santos http://www.santronics.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
Adam Novak wrote: Once the certificate expiration business is fixed, it should be fairly simple to make sure it's kept up to date so that this sort of thing doesn't happen again. Makes you wonder. Why is the concept of expiration required? Did the IETF expire, die? Did its value as an Organization go down and only valid on a year to year basis? It just seem so arbitrary for one to certify another and say to the world come X day, you are no longer the same trusted entity when what he is really saying "He didn't pay me like he suppose to every yet" Does that imply the IETF is now downgraded, in debt and can not be trusted? All rhetorical questions. After all, they did "Invent" it. It should be free to the IETF. :) Just consider there are some in the DKIM arena who wanted for the x= expiration tag to be deprecated and removed. -- Sincerely Hector Santos http://www.santronics.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: authenticated archives, was https
On 27 Aug 2011, at 19:42 , Joel jaeggli wrote: >> In the mean time, I would like TLS exterminated from the IETF website - any >> reason will do - since the cost to me far outweighs the benefit. So who >> decided to put it in, and on what grounds? Good question. For me it also causes more trouble than benefits. But let's split the difference and let the HTTP and HTTPS sites exist side by side for all pages that contain public information. > The datatracker, wikis, working group chairs pages, registration, > mailing list management and tools sites all support authentication, I > would find it completely unacceptable to pass my credentials or > activities I engaged in once authenticated in the clear. There's more to life than HTTPS. Such as digest authentication, which is probably sufficient for most of the above. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 26 Aug 2011, at 16:24 , Tim Bray wrote: > I'm increasingly coming to think that *everything* should be done with > TLS unless you can prove it's harmful. Call me paranoid, but given > the general state of the world, secure-by-default seems like the way > to go. -Tim That would be nice in a world where such security didn't slow everything down, especially on high RTT links. HTTPS really makes everything a whole lot slower on a mobile device, not to mention using extra battery power. There is absolutely no reason mailinglist archives or most other stuff on www.ietf.org needs more protection than any other random web page and as such imposing the additional overhead on other people is very annoying. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
- Original Message - From: "Joel jaeggli" To: "Doug Barton" Cc: "t.petch" ; "IETF Discussion" ; Sent: Sunday, August 28, 2011 9:55 PM > On 8/28/11 11:31 , Joel jaeggli wrote: > > On 8/26/11 14:00 , Doug Barton wrote: > >> Joel, > > > > "it doesn't" means that the mailing list archives do not require the use > > of https, if the entry point urls point to the https server that bad in > > this case... > > To be still more specific the mailman archives do not. the ibin archive > does. Joel Um, I do not understand that statement; mailman I know, ibin I do not, but either way, I am an archive user, not an e-mail administrator, and while I can access some archives with http:, notably from the web page for specific WG, others I cannot, notably from http://www.ietf.org/list/nonwg.html which is the only way I can access some of them, as far as I know: and on that page, there are some 250 html anchors with a scheme of 'https:' Edit the scheme to http: and the web site puts the 's' back in so either way, I am stuffed. Tom Petch > > If one has forgotten to renew a certificate before it expires, it takes > > time to get a new one issued. as an operational pratice is is necessary > > to track the issue and expiration dates of such resources. > > > >> I don't know what "It doesn't" is supposed to mean, but visiting > >> https://www.ietf.org/* today with firefox it is still reporting that the > >> certificate expired yesterday. > >> > >> Given the volume of discussion about the topic starting yesterday when > >> the problem started one could easily make a case for "it's still broken" > >> being a significant "issue." > >> > >> cc'ing the address listed as "Report Website Errors" on the home page. > >> > >> > >> Doug > >> > >> > >> On 08/26/2011 07:44, Joel jaeggli wrote: > >>> It doesn't... > >>> > >>> http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html > >>> > >>> On 8/26/11 00:18 , t.petch wrote: > >>>> Why does the IETF website consider it necessary to use TLS to access the mailing > >>>> list archives, when they all appeared without it, or any other security, in the > >>>> first place? > >>>> > >>>> Besides all the usual hassle of TLS, today the certificate is reported by IE as > >>>> expired, which sort of sums it up. > >>>> > >>>> Tom Petch > >>>> > >>>> ___ > >>>> Ietf mailing list > >>>> Ietf@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ietf > >>>> > >>> > >>> ___ > >>> Ietf mailing list > >>> Ietf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf > >> > >> > >> > > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 8/28/11 11:31 , Joel jaeggli wrote: > On 8/26/11 14:00 , Doug Barton wrote: >> Joel, > > "it doesn't" means that the mailing list archives do not require the use > of https, if the entry point urls point to the https server that bad in > this case... To be still more specific the mailman archives do not. the ibin archive does. > If one has forgotten to renew a certificate before it expires, it takes > time to get a new one issued. as an operational pratice is is necessary > to track the issue and expiration dates of such resources. > >> I don't know what "It doesn't" is supposed to mean, but visiting >> https://www.ietf.org/* today with firefox it is still reporting that the >> certificate expired yesterday. >> >> Given the volume of discussion about the topic starting yesterday when >> the problem started one could easily make a case for "it's still broken" >> being a significant "issue." >> >> cc'ing the address listed as "Report Website Errors" on the home page. >> >> >> Doug >> >> >> On 08/26/2011 07:44, Joel jaeggli wrote: >>> It doesn't... >>> >>> http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html >>> >>> On 8/26/11 00:18 , t.petch wrote: >>>> Why does the IETF website consider it necessary to use TLS to access the >>>> mailing >>>> list archives, when they all appeared without it, or any other security, >>>> in the >>>> first place? >>>> >>>> Besides all the usual hassle of TLS, today the certificate is reported by >>>> IE as >>>> expired, which sort of sums it up. >>>> >>>> Tom Petch >>>> >>>> ___ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>>> >>> >>> ___ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >> >> >> > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 8/26/11 14:00 , Doug Barton wrote: > Joel, "it doesn't" means that the mailing list archives do not require the use of https, if the entry point urls point to the https server that bad in this case... If one has forgotten to renew a certificate before it expires, it takes time to get a new one issued. as an operational pratice is is necessary to track the issue and expiration dates of such resources. > I don't know what "It doesn't" is supposed to mean, but visiting > https://www.ietf.org/* today with firefox it is still reporting that the > certificate expired yesterday. > > Given the volume of discussion about the topic starting yesterday when > the problem started one could easily make a case for "it's still broken" > being a significant "issue." > > cc'ing the address listed as "Report Website Errors" on the home page. > > > Doug > > > On 08/26/2011 07:44, Joel jaeggli wrote: >> It doesn't... >> >> http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html >> >> On 8/26/11 00:18 , t.petch wrote: >>> Why does the IETF website consider it necessary to use TLS to access the >>> mailing >>> list archives, when they all appeared without it, or any other security, in >>> the >>> first place? >>> >>> Besides all the usual hassle of TLS, today the certificate is reported by >>> IE as >>> expired, which sort of sums it up. >>> >>> Tom Petch >>> >>> ___ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>> >> >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
> On 8/27/2011 4:12 PM, t.petch wrote: > > Glen > > > > Me again. > > > > Just after I posted my last message, I received a post on the ietf-ssh list, > > hosted by netbsd.org, and looking through the 'Received: from' headers, as > > one > > does on a wet Saturday morning of a Bank Holiday weekend, there was TLS, > > used to > > submit the message to the server, so even spammers have caught on that TLS > > should be used everywhere. End to end? As a side note, the reason spammers use TLS to submit mail is obvious: It's required by many submission servers so they really don't have a choice. (The reason it's required is to protect the authentication exchange, not because there's any real expectation that it provides useful privacy protection for the submitted email itself.) > Apparently, from the POV of the spammer & his SMTP server. Email is a > store & forward system. In any case, my original question was not about > the definition of end-to-end, it was about Ned usage of the term "hop". I used the term "hop" in a very generic sense to refer to moving the data around. > Upon further analysis, however, it seems clear that he was referring to > the email archives as if they are something other than simple files (as > betrayed by his statement that "Don't pretend a transfer protection > mechanism covering exactly one hop provides real object security, > because it doesn't."); thus, the retrieval of the archived data would be > the last "hop" in the email system. And that's incorrect. For one thing, I often retrieve material from web sites and save it rather than looking at it right there on the screen. So the transfer of the material from the web server is in no way, shape, or form the final hop the information takes before it is consumed. As as Keith points out, I and many others am often forced to do such access through corporate-mandated proxies of various sorts - another hop. > There seem to be two problems with > this statement: one is taking the file transfer mechanism as if it was > part of the email system itself, Nobody is making any such claim. > which it obviously is not (downloading > an archived message is no different than downloading an RFC from a Web > site); the other being that someone, somewhere was pretending that TLS > does something that it was never designed to do (a straw man of, AFAICT, > Ned's invention -- I don't recall anybody making such a claim on this > thread, I was responding to the justification given for the use of https in this context. The exact words used were: > > The mail archives (and the minutes of the physical meetings) > > are the official record of the Working Groups, IETF, etc. > > Those archives should be available with a reasonably high > > level of integrity and authenticity. Nor was I the only, or even the first, to suggest that object security is needed for this sort of protection. > nor for that matter saying they _wanted_ "real object security" > applied to the archives, merely that it's not really a bad idea for a > person retrieving them to have some assurance that they came from the > IETF server and that they weren't modified in transit). And once again, nobody is saying that TLS doesn't give some very limited assurance along these lines - the notion that there are claims to the contrary is your own strawman. What we are saying is that there are also significant costs, those costs appear to be greater than the benefits in this case, and if there is real concern about archive integrity there are better ways to secure them. Anyway, this discussion is now well past it's sell-by date, so this will be my final response on the topic. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 8/27/2011 4:12 PM, t.petch wrote: > Glen > > Me again. > > Just after I posted my last message, I received a post on the ietf-ssh list, > hosted by netbsd.org, and looking through the 'Received: from' headers, as one > does on a wet Saturday morning of a Bank Holiday weekend, there was TLS, used > to > submit the message to the server, so even spammers have caught on that TLS > should be used everywhere. End to end? Apparently, from the POV of the spammer & his SMTP server. Email is a store & forward system. In any case, my original question was not about the definition of end-to-end, it was about Ned usage of the term "hop". Upon further analysis, however, it seems clear that he was referring to the email archives as if they are something other than simple files (as betrayed by his statement that "Don't pretend a transfer protection mechanism covering exactly one hop provides real object security, because it doesn't."); thus, the retrieval of the archived data would be the last "hop" in the email system. There seem to be two problems with this statement: one is taking the file transfer mechanism as if it was part of the email system itself, which it obviously is not (downloading an archived message is no different than downloading an RFC from a Web site); the other being that someone, somewhere was pretending that TLS does something that it was never designed to do (a straw man of, AFAICT, Ned's invention -- I don't recall anybody making such a claim on this thread, nor for that matter saying they _wanted_ "real object security" applied to the archives, merely that it's not really a bad idea for a person retrieving them to have some assurance that they came from the IETF server and that they weren't modified in transit). ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: authenticated archives, was https
On 8/27/11 08:35 , t.petch wrote: > In the mean time, I would like TLS exterminated from the IETF website - any > reason > will do - since the cost to me far outweighs the benefit. So who decided to > put > it in, and on what grounds? The datatracker, wikis, working group chairs pages, registration, mailing list management and tools sites all support authentication, I would find it completely unacceptable to pass my credentials or activities I engaged in once authenticated in the clear. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 8/27/11 7:25 AM, ned+i...@mauve.mrochek.com wrote: > I don't have an anwwer here, but the one thing I'm fairly sure of is that > blindly pushing TLS everywhere is not the solution a lot of folks believe > it is. I tend to think that the problem here (and I agree that it's a big one) isn't TLS, but that PKI as defined by pkix is very difficult to deploy correctly. Agreed. I've seen similar sorts of problems with digital signatures on email, but in those cases as often as not someone simply got the certificate contents wrong (or the user doesn't understand how to configure his mail client correctly and is using a name that doesn't appear in the certificate) rather that the cert has expired (although there's a lot of that, too). There's a substantial usability problem. Absolutely, and it's both architectural and operational - PKI is full of complex and subtle concepts that implementations don't exactly help you with. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: authenticated archives, was https
In the case of http: access, MSIE just times out. Repeat the request and it usually works; something has changed (could even be DNS). It works fine for me in IE on Windows 7 on an ordinary consumer DSL connection, click through the warning about the expired cert and the pages come right up. I suspect you will find that "my tools are broken" is not a persuasive argument to get people to remove security features, even fairly lame ones like this. Recently, DKIM was added to outgoing mail. The mail still works, the cost to me is small and the benefit - to me -is nil. Who decided to put it in? The IAOC, I expect. I find DKIM useful to skip mail filtering. Are you saying that people are not allowed to use RFC-standard security features until you, Tom, approve of them? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: authenticated archives, was https
Original Message - From: "John Levine" To: Sent: Saturday, August 27, 2011 4:31 PM > I can't tell what problem we're trying to solve here. The original > question (other than that whoever runs the IETF web site should > buy a new cert) seemed to have something to do with mailing list > archives. John Yes, more generally it is the creeping changes to the IETF service that makes work progressively more difficult. https: access to the IETF web site quite often fails for me, indeed access at all quite often fails. It never used to, and I am hard put to say just when it changed, but it was a year or two ago. In the case of http: access, MSIE just times out. Repeat the request and it usually works; something has changed (could even be DNS). With https:, the CRL downloads as does the source of the web page and then the process stalls, permanently; leaving it a couple of hours, or refreshing the page, with CRL now in place, and the little icon just goes on turning until it is time to stop work. Perhaps when I upgrade my PC it will work - or perhaps not, without a diagnosis I cannot tell. In the mean time, I would like TLS exterminated from the IETF website - any reason will do - since the cost to me far outweighs the benefit. So who decided to put it in, and on what grounds? Recently, DKIM was added to outgoing mail. The mail still works, the cost to me is small and the benefit - to me -is nil. Who decided to put it in? There has been a discussion about adding 'subject_prefix' on IETF_Discuss. (This is a welcome change, actually discussing it before doing it). For me, the added cost would be small, and the benefit nil. What is going to come next, and will we get any warning, or will the cost of IETF activity just go up again? Tom Petch I think it would be swell to know that the archives I > retrieved were the real ones, but what does real mean here? > > A - The messages sent by authenticated senders > B - The contents of the archive as of some past time when the > archives were created > C - The archives as they are on an IETF server now > D - The archives as presented by some presumably reliable piece > of software (pipermail) > E - Something else > > While option A might be nice, it's not going to happen without an > implausible level of S/MIME or PGP signing. > > Option B seems useful to me, since it defends against the threat of > accidental or deliberate bitrot. (An example might be restoring an > archived copy that had the addresses xxx'ed out.) > > Options C and D seem less useful. > > Harking back to a previous argument about signing RFCs, the way I > would do option B would be to publish hashes of the archive files in > enough places to be sure they're persistent, e.g., print the latest > set of hashes on the back of everyone's name card at IETF meetings. > > TLS for session privacy is nice, but I find negligible value in a > little lock icon in my browser that means only that one of the several > dozen cert issuers configured into my browser, most of whom I've never > heard of, and many of whom aren't even the organization in the cert > name, signed something. > > R's, > John > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 8/27/11 7:25 AM, ned+i...@mauve.mrochek.com wrote: I don't have an anwwer here, but the one thing I'm fairly sure of is that blindly pushing TLS everywhere is not the solution a lot of folks believe it is. I tend to think that the problem here (and I agree that it's a big one) isn't TLS, but that PKI as defined by pkix is very difficult to deploy correctly. I've seen similar sorts of problems with digital signatures on email, but in those cases as often as not someone simply got the certificate contents wrong (or the user doesn't understand how to configure his mail client correctly and is using a name that doesn't appear in the certificate) rather that the cert has expired (although there's a lot of that, too). There's a substantial usability problem. Melinda _______ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
> I'm increasingly coming to think that *everything* should be done with > TLS unless you can prove it's harmful. Call me paranoid, but given > the general state of the world, secure-by-default seems like the way > to go. -Tim This sentiment always sounds nice, but the devil is in the details. Back when STARTTLS was added to SMTP, a bunch of us thought this provided the means to do opportunistic encyption of email transport, so there was a push to deploy that. It was a total failure - it seems a certain large vendor with a very popular implementation borked their server so it advertised STARTTLS even though no certificate was installed and any attempt to negotiate TLS protection would end in failure. And since the negotiation failure left the connection in an unusable state, a new connection had to be tried, along with all the logic to prevent the new one from ending up in the same state. It tooks years before enough of the broken servers were fixed to try again, and by then service defaults and deployment guidelines were well established and the opportunity was gone as well. Of course this set of issues was unique to the situation. But with TLS it's always something - if it isn't broken default configurations, its incompatible cipher suites, or problems with certificate formats, or expired certificates, or dubious CAs, or major security holes in popular implementations, etc. etc. The bottom line is this stuff is just too complicated for mere mortals to get right, and the fact that they then proceed to get it wrong more often than not causes an enormous amount of trouble. In the present case, for example, you may think that an expired certificate is not a big deal. Not so. For one thing, the more people have to click on the "this really isn't secure, proceed anyway" button to get things done, the more likely they are to do it when it's a real attack and not a maintenance problem. And for another, there are some browser/certificate error combinations where there's no workaround - no amount of clicking "I agree" buttons will get you the data you're after. I don't have an anwwer here, but the one thing I'm fairly sure of is that blindly pushing TLS everywhere is not the solution a lot of folks believe it is. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: authenticated archives, was https
On Aug 27, 2011, at 10:31 AM, John Levine wrote: > TLS for session privacy is nice, but I find negligible value in a > little lock icon in my browser that means only that one of the several > dozen cert issuers configured into my browser, most of whom I've never > heard of, and many of whom aren't even the organization in the cert > name, signed something. +1. IMO browser vendors have made TLS nearly useless for web browsing by including so many default CAs; some with dubious integrity, and a few with a demonstrated lack of integrity. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 8/26/2011 12:18 AM, t.petch wrote: > Why does the IETF website consider it necessary to use TLS to access the > mailing list archives, when they all appeared without it, or any other > security, in the first place? There is a general move towards using https for all web exchanges, as already noted on this thread. When a server-side cert is used, this includes protection against man-in-the-middle attacks. As for providing confidentiality when the data are actually public, yeah, that's kind of wasted, but the web service can't know whether the data needs protecting. For example you might be logging in to your mailing list account. However, as Eliot notes, there is a degree of data authentication this provides. As for the alternative of object-based signing, that's good in theory, but not as well deployed -- and some current IETF wg activity seeks to remedy this(*) -- and therefore not an immediately superior choice. (As a fan of object-based signing, I would rather have the authentication be object-based.) On 8/26/2011 10:29 PM, Glen Zorn wrote: I could have sworn that TLS was an e2e mechanism. Maybe you're using the term "hop" in a manner unfamiliar to me? Evidently so. The likely disparity is with applications that have their own store-and-forward model, as already noted on this thread. TLS covers only one step (hop) in the sequence; by definition, that's not end2end. And note that this is a rather larger set of apps than most people realize. The modern web, for example, is highly store and forward at the application level. First, the author is typically far removed from the server that provides the data. Second, caches and proxies mediate the exchange. TLS protects none of the intermediary processes. In other words, with respect to application-level protection, TLS is equivalent to a link-level protocol. It is 'direct' between two apps participants during an immediate exchange. It does not cover the sequence of nodes at the application level. Having a sequence of TLS sessions provides protection of the communication exchanges, but does not protect within the nodes mediating the (apps-level) e2e sequence. In other words, "end to end" is a relative construct. Even email is not end2end, relative to some processes that use email, such as EDI... d/ (*) A fundamental issue that arises especially for object-based signing is which identifier to use. There is a very large difference between having it signed by the author's organization, versus by the web server operator, for example. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: authenticated archives, was https
I can't tell what problem we're trying to solve here. The original question (other than that whoever runs the IETF web site should buy a new cert) seemed to have something to do with mailing list archives. I think it would be swell to know that the archives I retrieved were the real ones, but what does real mean here? A - The messages sent by authenticated senders B - The contents of the archive as of some past time when the archives were created C - The archives as they are on an IETF server now D - The archives as presented by some presumably reliable piece of software (pipermail) E - Something else While option A might be nice, it's not going to happen without an implausible level of S/MIME or PGP signing. Option B seems useful to me, since it defends against the threat of accidental or deliberate bitrot. (An example might be restoring an archived copy that had the addresses xxx'ed out.) Options C and D seem less useful. Harking back to a previous argument about signing RFCs, the way I would do option B would be to publish hashes of the archive files in enough places to be sure they're persistent, e.g., print the latest set of hashes on the back of everyone's name card at IETF meetings. TLS for session privacy is nice, but I find negligible value in a little lock icon in my browser that means only that one of the several dozen cert issuers configured into my browser, most of whom I've never heard of, and many of whom aren't even the organization in the cert name, signed something. R's, John _______ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On Aug 26, 2011, at 10:24 AM, Tim Bray wrote: > I'm increasingly coming to think that *everything* should be done with > TLS unless you can prove it's harmful. Call me paranoid, but given > the general state of the world, secure-by-default seems like the way > to go. -Tim You're not alone. I think one reason this discussion suddenly flared up so dramatically is that this is at least as much a political issue as a technical one, and therefore not exactly the IETF's bailiwick. EFF certainly seems to think so: http://www.eff.org/https-everywhere Nowadays the only reason I can see for not wanting to use any form of encryption you can, anywhere and anytime you can, is a desire to make it easier for governments to snoop on you. Even flawed or partial schemes can provide some protection if deployed widely enough -- it's the same principle as steganography, more or less. -- Nathaniel___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
Glen Me again. Just after I posted my last message, I received a post on the ietf-ssh list, hosted by netbsd.org, and looking through the 'Received: from' headers, as one does on a wet Saturday morning of a Bank Holiday weekend, there was TLS, used to submit the message to the server, so even spammers have caught on that TLS should be used everywhere. End to end? Tom Petch - Original Message - From: "t.petch" To: "Glen Zorn" ; Cc: "IETF Discussion" Sent: Saturday, August 27, 2011 10:53 AM Subject: Re: https > - Original Message - > From: "Glen Zorn" > To: > Cc: "John C Klensin" ; "IETF Discussion" > Sent: Saturday, August 27, 2011 7:29 AM > Subject: Re: https > > > > On 8/26/2011 11:14 PM, ned+i...@mauve.mrochek.com wrote: > > > > > +1. If you want signatures, do them properly. Don't pretend a transfer > > > protection mechanism covering exactly one hop provides real object security, > > > because it doesn't. > > > > I could have sworn that TLS was an e2e mechanism. Maybe you're using > > the term "hop" in a manner unfamiliar to me? > > Glen > > Without a precise context, then e2e can mean anything, from ends of a fibre link > to ends of a communication between two sentient beings. > > On other lists, there is sometimes disagreement as to what TLS is, transport, > application or what. What it is not is a secure channel from application to > application, for that you need channel binding or some such, a problem which a > number of WGs have wrestled with, such as isms for SNMPv3 (which used its own > form of binding for both SSH and TLS between the secure transport and the > application). > > I regularly hear, and cringe at, statements in the media that you must check for > the padlock to know that you are secure. > > A) you do not know what cryptography is in use (my local library recently liked > SSL2 as a default) > > B) you do not know where the endpoints of the channel are > > TLS and padlocks are often a spurious miasma of security. > > Tom Petch > > > > > > And as for the "encrypt so the really secret stuff doesn't stand out" > argument, > > > that's fine as long as it doesn't cause inconvenience to anyone. That's > clearly > > > not the case here. And I'm sorry, the "mistakes were made" notion doesn't > > > really fly: Certificates aren't a "set it and forget it" thing, so if you > > > haven't noted expiration dates on someone's to-do list so they can be > updated > > > before expiration, you're not doing it right. > > > > Isn't "not doing it right" pretty much the definition of "mistake" > > (assuming no evil intent)? > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
- Original Message - From: "Glen Zorn" To: Cc: "John C Klensin" ; "IETF Discussion" Sent: Saturday, August 27, 2011 7:29 AM Subject: Re: https > On 8/26/2011 11:14 PM, ned+i...@mauve.mrochek.com wrote: > > > +1. If you want signatures, do them properly. Don't pretend a transfer > > protection mechanism covering exactly one hop provides real object security, > > because it doesn't. > > I could have sworn that TLS was an e2e mechanism. Maybe you're using > the term "hop" in a manner unfamiliar to me? Glen Without a precise context, then e2e can mean anything, from ends of a fibre link to ends of a communication between two sentient beings. On other lists, there is sometimes disagreement as to what TLS is, transport, application or what. What it is not is a secure channel from application to application, for that you need channel binding or some such, a problem which a number of WGs have wrestled with, such as isms for SNMPv3 (which used its own form of binding for both SSH and TLS between the secure transport and the application). I regularly hear, and cringe at, statements in the media that you must check for the padlock to know that you are secure. A) you do not know what cryptography is in use (my local library recently liked SSL2 as a default) B) you do not know where the endpoints of the channel are TLS and padlocks are often a spurious miasma of security. Tom Petch > > > And as for the "encrypt so the really secret stuff doesn't stand out" argument, > > that's fine as long as it doesn't cause inconvenience to anyone. That's clearly > > not the case here. And I'm sorry, the "mistakes were made" notion doesn't > > really fly: Certificates aren't a "set it and forget it" thing, so if you > > haven't noted expiration dates on someone's to-do list so they can be updated > > before expiration, you're not doing it right. > > Isn't "not doing it right" pretty much the definition of "mistake" > (assuming no evil intent)? > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
- Original Message - From: "Doug Barton" To: "Joel jaeggli" Cc: "t.petch" ; "IETF Discussion" ; Sent: Friday, August 26, 2011 11:00 PM Subject: Re: https > Joel, > > I don't know what "It doesn't" is supposed to mean, but visiting > https://www.ietf.org/* today with firefox it is still reporting that the > certificate expired yesterday. Doug How I interpreted the reply is that some mailing list archives can be accessed without using TLS, typically by going to the Working Group page and selecting the archive from there; v6ops is such a one. But as I pointed out yesterday, if you go to the ietf mailing list pages, such as http://www.ietf.org/list/nonwg.html then that contains some 250 or more html anchors with a scheme of https:, and that is the only way I know of accessing some of the archives (I was looking for the IESG comments on the approval of an I-D, comments which I had missed at announce time). I tried editing the URI to remove the 's' but the IETF website puts it back again:-( Tom Petch > > Given the volume of discussion about the topic starting yesterday when > the problem started one could easily make a case for "it's still broken" > being a significant "issue." > > cc'ing the address listed as "Report Website Errors" on the home page. > > > Doug > > > On 08/26/2011 07:44, Joel jaeggli wrote: > > It doesn't... > > > > http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html > > > > On 8/26/11 00:18 , t.petch wrote: > >> Why does the IETF website consider it necessary to use TLS to access the mailing > >> list archives, when they all appeared without it, or any other security, in the > >> first place? > >> > >> Besides all the usual hassle of TLS, today the certificate is reported by IE as > >> expired, which sort of sums it up. > >> > >> Tom Petch > >> > >> ___ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www.ietf.org/mailman/listinfo/ietf > >> > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 8/26/2011 11:14 PM, ned+i...@mauve.mrochek.com wrote: > +1. If you want signatures, do them properly. Don't pretend a transfer > protection mechanism covering exactly one hop provides real object security, > because it doesn't. I could have sworn that TLS was an e2e mechanism. Maybe you're using the term "hop" in a manner unfamiliar to me? > And as for the "encrypt so the really secret stuff doesn't stand out" > argument, > that's fine as long as it doesn't cause inconvenience to anyone. That's > clearly > not the case here. And I'm sorry, the "mistakes were made" notion doesn't > really fly: Certificates aren't a "set it and forget it" thing, so if you > haven't noted expiration dates on someone's to-do list so they can be updated > before expiration, you're not doing it right. Isn't "not doing it right" pretty much the definition of "mistake" (assuming no evil intent)? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
--On Friday, August 26, 2011 16:15 -0400 Eric Burger wrote: > Two thoughts. > > On the one hand, Ned is absolutely correct: the thing we want > to make absolutely sure of is the integrity of the object. The > way of doing that is making sure the object itself can prove > its integrity. In the messaging world, we do this with > S/MIME. The use of TLS for SMTP or IMAP does not convey any > integrity assertions for the object. Note this object should > be signed by me when you receive it, by the way. And it verifies too... sort of. Note that the IETF mailing list machinery tries to prevent it from doing so by appending a footer to tell everyone who it is (independent of the standard List-* headers that contain the same information). Another separate problem, but definitely falling into the "dogfood... yum" category. > On the other hand, while TLS is not at all sufficient for the > integrity of the object, it is necessary to protect the > individual accessing the object. There are a number of > countries where asking for the RFCs relating to privacy, > security, and threats to such too many times could get you > arrested. Yes, although it isn't entirely clear that TLS actually provides enough protection in practice. A sufficiently paranoid government with those concerns would either force the connections through proxies that it controlled (see Keith's note) or would notice connections to IETF servers and "inquire", through out-of-band means, about what was being retrieved. There are ways to protect against that risk, but assuming that unadorned https is sufficient is almost certainly naive. > Likewise, the presumption is the object might be > signed, but it would be insane and useless to encrypt the > object. However, there are many, many times one would want > the object encrypted, even if only to compress it. Sure. If TLS actually worked for its intended purpose in the overwhelming number of cases, nothing that Ned or I have said would argue against using it. In that regard, the problems are that it is assumed to solve several problems for which it is useless and several others, including your example above, for which its effectiveness is dubious against an attacker with sufficient non-network resources. > Given that, the question should not be, "Why are we using TLS > if the object is not private?," but "What are we not using > secure connections for all IETF access, over any modality?" > > One of the answers seems to be, "Because it sucks." That is > the sentiment of the message below. > So we are eating our dog food, and we are getting indigestion. > Sounds like an opportunity to fix it! I think it is more than that. If we (and the Secretariat and IASA) cannot get it together to keep certs up to date, or at least to get them updated _very_ quickly when someone notices that they have expired (note that it is now only a few minutes short of 24 hours since the thing expired), we are sending a pretty strong message to the community that we don't care and no one else should either. Remember that the message browsers pop up when an invalid or expired certificate is encountered is totally incomprehensible to a typical luser, offering only choices of not accessing a site that contains useful information and that was valid before and accepting the cert, errors and all. The more valid sites there are with invalid certificates, the more we train the user to accept those invalid certificates, rendering the whole certificate idea (and TLS with it) pointless. By choosing to contribute to that problem, the IETF undermines the utility of TLS for addressing the real issues of server authentication and client-> server encryption that it was primarily intended to address. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
Joel, I don't know what "It doesn't" is supposed to mean, but visiting https://www.ietf.org/* today with firefox it is still reporting that the certificate expired yesterday. Given the volume of discussion about the topic starting yesterday when the problem started one could easily make a case for "it's still broken" being a significant "issue." cc'ing the address listed as "Report Website Errors" on the home page. Doug On 08/26/2011 07:44, Joel jaeggli wrote: > It doesn't... > > http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html > > On 8/26/11 00:18 , t.petch wrote: >> Why does the IETF website consider it necessary to use TLS to access the >> mailing >> list archives, when they all appeared without it, or any other security, in >> the >> first place? >> >> Besides all the usual hassle of TLS, today the certificate is reported by IE >> as >> expired, which sort of sums it up. >> >> Tom Petch >> >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
Two thoughts. On the one hand, Ned is absolutely correct: the thing we want to make absolutely sure of is the integrity of the object. The way of doing that is making sure the object itself can prove its integrity. In the messaging world, we do this with S/MIME. The use of TLS for SMTP or IMAP does not convey any integrity assertions for the object. Note this object should be signed by me when you receive it, by the way. On the other hand, while TLS is not at all sufficient for the integrity of the object, it is necessary to protect the individual accessing the object. There are a number of countries where asking for the RFCs relating to privacy, security, and threats to such too many times could get you arrested. Likewise, the presumption is the object might be signed, but it would be insane and useless to encrypt the object. However, there are many, many times one would want the object encrypted, even if only to compress it. Given that, the question should not be, "Why are we using TLS if the object is not private?," but "What are we not using secure connections for all IETF access, over any modality?" One of the answers seems to be, "Because it sucks." That is the sentiment of the message below. So we are eating our dog food, and we are getting indigestion. Sounds like an opportunity to fix it! -- - Eric On Aug 26, 2011, at 3:32 PM, Melinda Shore wrote: > On 08/26/2011 11:22 AM, Adam Novak wrote: >> For what reasons? Is it that things scheduled every year or every ten >> years are easy for admins to miss? Or is it that it's hard to stay on >> top of certificate revocations when they occur? > > Firewall researchers have found at least one error of some sort in > 99% (yes, really) of the firewall rulesets they've examined. If > I had to guess how many PKI deployments have problems, I'd put it in > the same ballpark. They seem to fall into several broad categories > 1) naming (including SANs), 2) expiration, 3) faulty trust > establishment. These may or may not be fixable, but what doesn't > appear to be fixable is that too people don't really understand what > certificates represent, the difference between a certificate and > a key, or what it means to TLS-protect traffic. > > Listen to Ned, Adam. He's right. > > Melinda > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 08/26/2011 11:22 AM, Adam Novak wrote: For what reasons? Is it that things scheduled every year or every ten years are easy for admins to miss? Or is it that it's hard to stay on top of certificate revocations when they occur? Firewall researchers have found at least one error of some sort in 99% (yes, really) of the firewall rulesets they've examined. If I had to guess how many PKI deployments have problems, I'd put it in the same ballpark. They seem to fall into several broad categories 1) naming (including SANs), 2) expiration, 3) faulty trust establishment. These may or may not be fixable, but what doesn't appear to be fixable is that too people don't really understand what certificates represent, the difference between a certificate and a key, or what it means to TLS-protect traffic. Listen to Ned, Adam. He's right. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On Aug 26, 2011, at 3:22 PM, Adam Novak wrote: > On Fri, Aug 26, 2011 at 1:12 PM, Ned Freed wrote: >>> It ensures that what you're getting is the same as what the IETF has >>> on file, >> >> No, it really doesn't do that. There can be, and usually are, a lot of steps >> involves besides the one https hop. >> > > What other steps are there? HTTPS prevents what the web server sends > from being tampered with on its way to the browser. If the web server > storing the archives is itself trusted, this would seem to be all that > is needed. There can be web proxies on the front end (if the client is configured to use them) and the web server itself can be implemented in such a way as to retrieve content from other servers (via a number of means, e.g. NFS, CIFS, web services calls, sql calls). Though I don't know whether the latter is the case for content served from IETF's servers. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On Fri, Aug 26, 2011 at 1:12 PM, Ned Freed wrote: >> It ensures that what you're getting is the same as what the IETF has >> on file, > > No, it really doesn't do that. There can be, and usually are, a lot of steps > involves besides the one https hop. > What other steps are there? HTTPS prevents what the web server sends from being tampered with on its way to the browser. If the web server storing the archives is itself trusted, this would seem to be all that is needed. Obviously HTTPS is not a solution to long-term preservation of the integrity of the mailing list database itself. What protections, if any, are currently in place to protect the archive from tampering on IETF's end? Perhaps the whole thing should be signed by someone official at regular intervals? > > I'm sorry, but the notion that the present use of https provides any > sort of protection against this sort of thing is just silly. The simple > facts that the archives are also available via regular http and that > there is no stated policy about the availability of archives via https > means the present setup is completely vulnerable to downgrade attacks. > A downgrade attack is certainly possible. But there are measures available to ensure that, once an HTTPS connection has been established once, future HTTP sessions will be rejected client-side. And creating an official policy and going HTTPS-only could be done relatively easily. If HTTPS everywhere is where the Web should be going, then IETF should be leading the charge. > 10+ years of experience with multiple certificates having multiple failures > says this is, at best, a crapshoot. > For what reasons? Is it that things scheduled every year or every ten years are easy for admins to miss? Or is it that it's hard to stay on top of certificate revocations when they occur? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
> On Fri, Aug 26, 2011 at 11:14 AM, wrote: > > > > +1. If you want signatures, do them properly. Don't pretend a transfer > > protection mechanism covering exactly one hop provides real object security, > > because it doesn't. > > > It ensures that what you're getting is the same as what the IETF has > on file, No, it really doesn't do that. There can be, and usually are, a lot of steps involves besides the one https hop. > and (assuming you trust the IETF's archive integrity, which > is a separate problem) On the contrary, it's the same problem. You're just pretending that solving an insignificant subset of that problem is useful. It isn't. > what everyone else on the list received. This, OTOH, *is* a separate problem, one that isn't addressed in any way by https on archive archive access. Nor does a signed archive address this issue. Nonrepudiation of delivery is in fact a very difficult problem to solve - the algorithms I'm aware of for it either involve a TTP or are exceptionaly ugly - and the fact that the architecture of our email services isn't designed for it doesn't exactly help. (In case you care, it's the nontransactional nature of POP and IMAP that gets in the way of doing nonrepudiation of delivery at the email protocol level.) We're very lucky that we don't operate in a regime where this is actually a requirement. (And such regimes do exist, although the solutions they actually use tend to be hacks.) > It > seems to me it's more important to know that than to know that stuff > sent to the list actually came from who it claims to come from. Does > it really matter if a proposed standard wasn't really designed by who > the archive says it was designed by? And now you're talking about yet a third problem - nonrepudiation of submission. It's completely doable, but only by significantly increasing the barriers to participation by requiring signed messages. I don't believe the benefits come even close to the costs. > > And as for the "encrypt so the really secret stuff doesn't stand out" > > argument, > > that's fine as long as it doesn't cause inconvenience to anyone. That's > > clearly > > not the case here. And I'm sorry, the "mistakes were made" notion doesn't > > really fly: Certificates aren't a "set it and forget it" thing, so if you > > haven't noted expiration dates on someone's to-do list so they can be > > updated > > before expiration, you're not doing it right. > Yeah, it seems like the IETF would be on top of certificate > expiration, having invented it. But I think having the encryption is a > very good thing. Some government interests would be happy to keep > information about some aspects of IETF business away from their > citizenry, and have the resources to launch a MITM attack. (Of course, > those governments may also have the resources to sign a fake > certificate, but that is, again, a separate problem.) I'm sorry, but the notion that the present use of https provides any sort of protection against this sort of thing is just silly. The simple facts that the archives are also available via regular http and that there is no stated policy about the availability of archives via https means the present setup is completely vulnerable to downgrade attacks. Again, if you really care about this sort of stuff, the archives need to be timestamped and signed. > Once the certificate expiration business is fixed, it should be fairly > simple to make sure it's kept up to date so that this sort of thing > doesn't happen again. 10+ years of experience with multiple certificates having multiple failures says this is, at best, a crapshoot. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On Fri, Aug 26, 2011 at 1:13 PM, Hector Santos wrote: > Makes you wonder. Why is the concept of expiration required? Did the IETF > expire, die? Did its value as an Organization go down and only valid on a > year to year basis? As I understand it, expiration is supposed to solve the problem of someone getting their hands on your old certificates and impersonating you. In order to impersonate you, not only do they have to get into your system, they have to have done it in the last year or so. It also keeps certificates for domains from outliving domain registrations for too long. If you don't have the domain when you go to renew the certificate, the CA shouldn't renew it. I guess it also keeps revocation lists short. You only have to remember that a certain certificate was compromised until it expires, instead of forever. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On Fri, Aug 26, 2011 at 11:14 AM, wrote: > > +1. If you want signatures, do them properly. Don't pretend a transfer > protection mechanism covering exactly one hop provides real object security, > because it doesn't. > It ensures that what you're getting is the same as what the IETF has on file, and (assuming you trust the IETF's archive integrity, which is a separate problem) what everyone else on the list received. It seems to me it's more important to know that than to know that stuff sent to the list actually came from who it claims to come from. Does it really matter if a proposed standard wasn't really designed by who the archive says it was designed by? > And as for the "encrypt so the really secret stuff doesn't stand out" > argument, > that's fine as long as it doesn't cause inconvenience to anyone. That's > clearly > not the case here. And I'm sorry, the "mistakes were made" notion doesn't > really fly: Certificates aren't a "set it and forget it" thing, so if you > haven't noted expiration dates on someone's to-do list so they can be updated > before expiration, you're not doing it right. Yeah, it seems like the IETF would be on top of certificate expiration, having invented it. But I think having the encryption is a very good thing. Some government interests would be happy to keep information about some aspects of IETF business away from their citizenry, and have the resources to launch a MITM attack. (Of course, those governments may also have the resources to sign a fake certificate, but that is, again, a separate problem.) Once the certificate expiration business is fixed, it should be fairly simple to make sure it's kept up to date so that this sort of thing doesn't happen again. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
- Original Message - From: "Joel jaeggli" To: "t.petch" Cc: "IETF Discussion" Sent: Friday, August 26, 2011 4:44 PM Subject: Re: https > It doesn't... > > http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html Try the source of http://www.ietf.org/list/discussion.html where https: outumbers http: or http://www.ietf.org/list/nonwg.html where I run out of numbers before I run out of https: Tom Petch > > On 8/26/11 00:18 , t.petch wrote: > > Why does the IETF website consider it necessary to use TLS to access the mailing > > list archives, when they all appeared without it, or any other security, in the > > first place? > > > > Besides all the usual hassle of TLS, today the certificate is reported by IE as > > expired, which sort of sums it up. > > > > Tom Petch > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
> --On Friday, August 26, 2011 09:43 -0400 Donald Eastlake > wrote: > >> Yup, but why are we using https at all? Who decided, and > >> please would they undecide? Unexpired certificates can be > >> circumvented, but all too often, the https parts of the web > >> site just do not work and, more importantly, I think it wrong > >> to use industrial grade security where none is called for. > > > > The mail archives (and the minutes of the physical meetings) > > are the official record of the Working Groups, IETF, etc. > > Those archives should be available with a reasonably high > > level of integrity and authenticity. > Don, > If that is the goal, wouldn't we be lots better off just > digitally signing those things, just as we are gradually > starting to create signatures for I-Ds, etc.? Verifying that > one is talking to the right server and that the content is not > tampered with in transit is all well and good, but it doesn't > protect against compromised documents or a compromised server at > all. +1. If you want signatures, do them properly. Don't pretend a transfer protection mechanism covering exactly one hop provides real object security, because it doesn't. And as for the "encrypt so the really secret stuff doesn't stand out" argument, that's fine as long as it doesn't cause inconvenience to anyone. That's clearly not the case here. And I'm sorry, the "mistakes were made" notion doesn't really fly: Certificates aren't a "set it and forget it" thing, so if you haven't noted expiration dates on someone's to-do list so they can be updated before expiration, you're not doing it right. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 8/26/11 5:43 AM, Donald Eastlake wrote: The mail archives (and the minutes of the physical meetings) are the official record of the Working Groups, IETF, etc. Those archives should be available with a reasonably high level of integrity and authenticity. I'm not fully sold, but either way it seems to me that a technology with such a very, very high error rate in deployment probably needs some reconsideration. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
It doesn't... http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html On 8/26/11 00:18 , t.petch wrote: > Why does the IETF website consider it necessary to use TLS to access the > mailing > list archives, when they all appeared without it, or any other security, in > the > first place? > > Besides all the usual hassle of TLS, today the certificate is reported by IE > as > expired, which sort of sums it up. > > Tom Petch > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
--On Friday, August 26, 2011 09:43 -0400 Donald Eastlake wrote: >> Yup, but why are we using https at all? Who decided, and >> please would they undecide? Unexpired certificates can be >> circumvented, but all too often, the https parts of the web >> site just do not work and, more importantly, I think it wrong >> to use industrial grade security where none is called for. > > The mail archives (and the minutes of the physical meetings) > are the official record of the Working Groups, IETF, etc. > Those archives should be available with a reasonably high > level of integrity and authenticity. Don, If that is the goal, wouldn't we be lots better off just digitally signing those things, just as we are gradually starting to create signatures for I-Ds, etc.? Verifying that one is talking to the right server and that the content is not tampered with in transit is all well and good, but it doesn't protect against compromised documents or a compromised server at all. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
- Original Message - From: "Donald Eastlake" To: "t.petch" Cc: "IETF Discussion" Sent: Friday, August 26, 2011 3:43 PM On Fri, Aug 26, 2011 at 4:39 AM, t.petch wrote: > - Original Message - > From: "SM" > To: "t.petch" > Cc: "IETF Discussion" > > >> Hi Tom, >> At 00:18 26-08-2011, t.petch wrote: >> >Besides all the usual hassle of TLS, today the certificate is >> >reported by IE as >> >expired, which sort of sums it up. >> >> Already reported to ietf-action@. >> >> Regards, >> -sm >> >> P.S. My experience of ietf-action@ is that they are responsive and do >> fix problems that are reported. > > Yup, but why are we using https at all? Who decided, and please would they > undecide? Unexpired certificates can be circumvented, but all too often, the > https parts of the web site just do not work and, more importantly, I think it > wrong to use industrial grade security where none is called for. The mail archives (and the minutes of the physical meetings) are the official record of the Working Groups, IETF, etc. Those archives should be available with a reasonably high level of integrity and authenticity. Ys but for the mail archives they provide authenticity and integrity only as far as the Man In The Middle, namely the IETF server/process; this adds a spurious, to me, impression of security for e-mails that could have come from anyone masquerading as anyone. And when there is some defence against masquerade - DKIM (and yes I know what it does and its limitations) - then the DKIM signature is invalidated by the list process, that MITM again. If there are requirements for archives to be provided with a degree of trust, eg in response to a subpoena, then that should be a separate process, leaving us ordinary folk to access them in a simple and straighforward manner. Tom Petch Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com > Tom Petch > > >> > > _______ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
I'm increasingly coming to think that *everything* should be done with TLS unless you can prove it's harmful. Call me paranoid, but given the general state of the world, secure-by-default seems like the way to go. -Tim On Fri, Aug 26, 2011 at 1:39 AM, t.petch wrote: > - Original Message - > From: "SM" > To: "t.petch" > Cc: "IETF Discussion" > Subject: Re: https > > >> Hi Tom, >> At 00:18 26-08-2011, t.petch wrote: >> >Besides all the usual hassle of TLS, today the certificate is >> >reported by IE as >> >expired, which sort of sums it up. >> >> Already reported to ietf-action@. >> >> Regards, >> -sm >> >> P.S. My experience of ietf-action@ is that they are responsive and do >> fix problems that are reported. > > Yup, but why are we using https at all? Who decided, and please would they > undecide? Unexpired certificates can be circumvented, but all too often, the > https parts of the web site just do not work and, more importantly, I think it > wrong to use industrial grade security where none is called for. > > Tom Petch > > >> > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On Fri, Aug 26, 2011 at 4:39 AM, t.petch wrote: > - Original Message - > From: "SM" > To: "t.petch" > Cc: "IETF Discussion" > Subject: Re: https > > >> Hi Tom, >> At 00:18 26-08-2011, t.petch wrote: >> >Besides all the usual hassle of TLS, today the certificate is >> >reported by IE as >> >expired, which sort of sums it up. >> >> Already reported to ietf-action@. >> >> Regards, >> -sm >> >> P.S. My experience of ietf-action@ is that they are responsive and do >> fix problems that are reported. > > Yup, but why are we using https at all? Who decided, and please would they > undecide? Unexpired certificates can be circumvented, but all too often, the > https parts of the web site just do not work and, more importantly, I think it > wrong to use industrial grade security where none is called for. The mail archives (and the minutes of the physical meetings) are the official record of the Working Groups, IETF, etc. Those archives should be available with a reasonably high level of integrity and authenticity. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com > Tom Petch > > >> > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
+100 On Aug 26, 2011, at 6:50 AM, Scott Schmit wrote: > On Fri, Aug 26, 2011 at 09:18:41AM +0200, t.petch wrote: >> Why does the IETF website consider it necessary to use TLS to access >> the mailing list archives, when they all appeared without it, or any >> other security, in the first place? > > TLS provides more than confidentiality--it also provides authenticity. > If I were living in a hostile regime, I'd appreciate knowing that the > RFCs, etc that I'm getting really come from the IETF unmodified. > > Also, as a general principle, I'd rather someone not be able to read > over my shoulder, even if it is harmless stuff. Using encryption only > when I need it makes all of my encrypted traffic less secure. > > For example, if I were out to modify the traffic you read to make sure > that you didn't even know that a working group existed, I'd have a lot > easier time of it if you use DNS without DNSSEC, HTTP without TLS, TLS > without HASTLS, DANE, HSTS, etc. Now, not all of that is completed > protocol work, but one step at a time. > >> Besides all the usual hassle of TLS, today the certificate is reported >> by IE as expired, which sort of sums it up. > > Mistakes happen. Hopefully lessons are learned so that they don't get > repeated. > > If it's a protocol problem, whose fault is that but ours? > > -- > Scott Schmit > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
"t.petch" writes: > Why does the IETF website consider it necessary to use TLS to access > the mailing list archives, when they all appeared without it, or any > other security, in the first place? Archives have long been and continue to be available at ftp://ftp.ietf.org/ietf-mail-archive/ Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On Fri, Aug 26, 2011 at 09:18:41AM +0200, t.petch wrote: > Why does the IETF website consider it necessary to use TLS to access > the mailing list archives, when they all appeared without it, or any > other security, in the first place? TLS provides more than confidentiality--it also provides authenticity. If I were living in a hostile regime, I'd appreciate knowing that the RFCs, etc that I'm getting really come from the IETF unmodified. Also, as a general principle, I'd rather someone not be able to read over my shoulder, even if it is harmless stuff. Using encryption only when I need it makes all of my encrypted traffic less secure. For example, if I were out to modify the traffic you read to make sure that you didn't even know that a working group existed, I'd have a lot easier time of it if you use DNS without DNSSEC, HTTP without TLS, TLS without HASTLS, DANE, HSTS, etc. Now, not all of that is completed protocol work, but one step at a time. > Besides all the usual hassle of TLS, today the certificate is reported > by IE as expired, which sort of sums it up. Mistakes happen. Hopefully lessons are learned so that they don't get repeated. If it's a protocol problem, whose fault is that but ours? -- Scott Schmit ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
Bert, Tom, I don't see this as being a matter of encrypting, but rather providing verifiable information the community. What's more, in as much as the IETF is a trusted site by many, it's probably a good idea to have at least some confidence that when you click on a link, you're not going to get hacked. Finally, the IETF designed this system, and if we don't like the fragility, perhaps we should fix it. There's a saying about eating one's own dogfood. After all, if we won't eat ours, why should anyone else? By the way, Tom, you're not quite right. Mail sent out from the IETF list (including this one and the one you sent to the list) is signed by the IETF with DKIM. Again, eating our own dogfood. Eliot _______ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
Yup, but why are we using https at all? Who decided, and please would they undecide? Unexpired certificates can be circumvented, but all too often, the https parts of the web site just do not work and, more importantly, I think it wrong to use industrial grade security where none is called for. I agree with Tom here. In my understanding, all IETF communications and (mailing list) discussions are open and public. So why do we need to protect/encrypt? I would say: protect what must be protected but don't protect what is not supposed to be protected. just encrypting everything seems incorrect to me. Bert Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
- Original Message - From: "SM" To: "t.petch" Cc: "IETF Discussion" Subject: Re: https > Hi Tom, > At 00:18 26-08-2011, t.petch wrote: > >Besides all the usual hassle of TLS, today the certificate is > >reported by IE as > >expired, which sort of sums it up. > > Already reported to ietf-action@. > > Regards, > -sm > > P.S. My experience of ietf-action@ is that they are responsive and do > fix problems that are reported. Yup, but why are we using https at all? Who decided, and please would they undecide? Unexpired certificates can be circumvented, but all too often, the https parts of the web site just do not work and, more importantly, I think it wrong to use industrial grade security where none is called for. Tom Petch > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
Hi Tom, At 00:18 26-08-2011, t.petch wrote: Besides all the usual hassle of TLS, today the certificate is reported by IE as expired, which sort of sums it up. Already reported to ietf-action@. Regards, -sm P.S. My experience of ietf-action@ is that they are responsive and do fix problems that are reported. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
https
Why does the IETF website consider it necessary to use TLS to access the mailing list archives, when they all appeared without it, or any other security, in the first place? Besides all the usual hassle of TLS, today the certificate is reported by IE as expired, which sort of sums it up. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Request about: https://datatracker.ietf.org/ipr/1026/
To whom it may concern, This is about: "Transport Layer Security (TLS) Authorization Extensions" (draft-housley-tls-authz-extns-07) Patent information: 11/234,404 ; 60/646,749 ; PCT/US2006/001342 Which can be found by reading the document: https://datatracker.ietf.org/ipr/1026/ The section where RedPhone Security asserts that the protocol would hold nothing that infringes the patent, they then say that there are four ways to do business with this protocol, and implementing these methods would infringe what they call their IPR. Then they go on to state: "RedPhone Security agrees to grant licenses for such uses in a fair and nondiscriminatory manner. This statement applies to the Disclosed Patent Information, including all amendments in all nations as published during the course of prosecution." This statement says "you now need licences to make the internet work". This is an attempt to put a toll booth on an onramp to the internet, even if this toll booth is cashless it would be unforgivable to allow such a construction. Precedence as we all know is a bad thing, and this would be a really bad case of it the start of the closing of the highway that is the internet. Therefore I strongly recommend that this draft be dropped until such time as RedPhone Agrees to allow a complete and free use of any works they feel they can lay claim to in the implementation of this protocol where the methods of authentication against violate their IPR. The only offer that would be acceptable would be for RedPhone security to grant all parties involved a full and free use of any of their IP that is associated with this protocol. If you wish to run a sanity test why not ask "What would Jon Postel have said in this case?". Regards, Paul O'Malley _______ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
