ietf.org · Domains · Slashdot Mirror

Problems with OpenId by Atrus5 · 2005-07-05 19:10 · Score: 2, Interesting · on LiveJournal Founder Launches OpenID System

I've expounded on why OpenID is insecure and I believe it is unnecessarily complicated.

Problems with OpenIDI put off reading the OpenID spec because I though it was probably flawed. Now I just feel applying my head to my desk.

OpenID is led by with this philosophy:

The point of OpenID is to be dead simple, short-comings and all, so it's actually adopted.

The above is taken from a discussion of vulnerabilities. The problem with this lowest common denominator approach is that it's horribly broken. OpenID is currently no better than just giving the URL of your blog.

The number one problem is the complete lack of integrity checking. Everything in OpenID seems to be perfectly happy to let their requests be modified in transit. I think the problem with this are pretty damn obvious: nothing can be trusted. Fortunately, fixing this is pretty simple: use TLS. In today's shared hosting environment, you probably want to require support for server name indication.

Another brilliant idea: transmit the key that you'll use for signing later in plaintext.

Yes, you can ask for DH-SHA1 encryption and get back a plaintext secret. If this troubles you, don't use the handle and instead use dumb mode with that server. (and if somebody sniffed the plaintext secret, it won't matter, since you'll never accept queries using that assoc_handle). If the server can't do DH, it's probably limited in some way, but using dumb mode is still safe, if not a little slower.

I believe "limited in some way" means "completely insecure." "Dumb mode" is not safe because there's no key associated with the server, so there's no way to ensure you're talking to the same one or that someone isn't tampering.

I also don't see much point in using a symmetric key for speed and security when you're just encrypting a short string. It's so tiny that both improvements are similarly small.

Perhaps the biggest problem with OpenID is it's reliance on sending a user to another page to login. It's just too easy to spoof a page and fool most people. Even better, you can open a window using Javascript and hide the location bar. Even if you normally use TLS, most people probably won't notice if it's missing or the certificate is different. Also, most sites (including LiveJournal) include a completely insecure assurance that you're secure. For example, LiveJournal says "LiveJournal Secure Site "

A simpler and more secure alternativeThe only way to fix this is (gasp) get users to carry their own keys. If you stored your key in a bookmarklet or extension, you could sign something with it. This is completely feasible because Javascript cryptography implementation is done. You could submit your public key with the signed comment. If you wanted to associate yourself with a URL, all you need to do is link to a page with the public key. If the same public key can be used for the signature.. That's right, no special identity server is needed. The public key could be submitted directly or it can be linked to. It might be a pain to write out the entire URL to the key, so perhaps autodiscovery-from-HTML should be supported:
<link rel="openpgp.key" href="http://www.livejournal.com/pubkey.bml?user=a trustheotaku" />
Note that no TLS is needed. The signature is secure in and of itself. If you want to support all the fanciness (e.g. revocation) of OpenPGP (spec), then you just need the

Problems with OpenId by Atrus5 · 2005-07-05 19:10 · Score: 2, Interesting · on LiveJournal Founder Launches OpenID System

I've expounded on why OpenID is insecure and I believe it is unnecessarily complicated.

Problems with OpenIDI put off reading the OpenID spec because I though it was probably flawed. Now I just feel applying my head to my desk.

OpenID is led by with this philosophy:

The point of OpenID is to be dead simple, short-comings and all, so it's actually adopted.

The above is taken from a discussion of vulnerabilities. The problem with this lowest common denominator approach is that it's horribly broken. OpenID is currently no better than just giving the URL of your blog.

The number one problem is the complete lack of integrity checking. Everything in OpenID seems to be perfectly happy to let their requests be modified in transit. I think the problem with this are pretty damn obvious: nothing can be trusted. Fortunately, fixing this is pretty simple: use TLS. In today's shared hosting environment, you probably want to require support for server name indication.

Another brilliant idea: transmit the key that you'll use for signing later in plaintext.

Yes, you can ask for DH-SHA1 encryption and get back a plaintext secret. If this troubles you, don't use the handle and instead use dumb mode with that server. (and if somebody sniffed the plaintext secret, it won't matter, since you'll never accept queries using that assoc_handle). If the server can't do DH, it's probably limited in some way, but using dumb mode is still safe, if not a little slower.

I believe "limited in some way" means "completely insecure." "Dumb mode" is not safe because there's no key associated with the server, so there's no way to ensure you're talking to the same one or that someone isn't tampering.

I also don't see much point in using a symmetric key for speed and security when you're just encrypting a short string. It's so tiny that both improvements are similarly small.

Perhaps the biggest problem with OpenID is it's reliance on sending a user to another page to login. It's just too easy to spoof a page and fool most people. Even better, you can open a window using Javascript and hide the location bar. Even if you normally use TLS, most people probably won't notice if it's missing or the certificate is different. Also, most sites (including LiveJournal) include a completely insecure assurance that you're secure. For example, LiveJournal says "LiveJournal Secure Site "

A simpler and more secure alternativeThe only way to fix this is (gasp) get users to carry their own keys. If you stored your key in a bookmarklet or extension, you could sign something with it. This is completely feasible because Javascript cryptography implementation is done. You could submit your public key with the signed comment. If you wanted to associate yourself with a URL, all you need to do is link to a page with the public key. If the same public key can be used for the signature.. That's right, no special identity server is needed. The public key could be submitted directly or it can be linked to. It might be a pain to write out the entire URL to the key, so perhaps autodiscovery-from-HTML should be supported:
<link rel="openpgp.key" href="http://www.livejournal.com/pubkey.bml?user=a trustheotaku" />
Note that no TLS is needed. The signature is secure in and of itself. If you want to support all the fanciness (e.g. revocation) of OpenPGP (spec), then you just need the

I don't want to be part of a community by blair1q · 2005-07-03 11:25 · Score: 1 · on Windows Software Ugly, Boring & Uninspired

I don't want my computer to clique me into a particular "community".

I want it to be a toolbox that allows me to be a part of many communities I choose to join.

And if you don't like the software available, it is, you know, possible to write your own, to your - or the world's[1][2][3][4][5][6] - standards of function, style, consistency, robustness, and hipness.

So is it Windows's fault that it's too broad and not restrictive enough on new tools, or is it Mac's fault that it's provincial and overweaning?

Re: FTP overhead versus HTTP by Trepalium · 2005-07-03 09:52 · Score: 1 · on David Clark: Rebuild the Internet

In short, for you to say that base64 encoding does not occur on HTTP connections, is wrong. Period.

Well, I'm just getting this directly from RFC 2616.

19.4 Differences Between HTTP Entities and RFC 2045 Entities

19.4.5 No Content-Transfer-Encoding

HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client.
Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol being used. Such a proxy or gateway SHOULD label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over the destination protocol.

As I said, I've seen base64 used in HTTP before, but not in the transfer itself. I've seen it encoded into cookies and form elements (and maybe view-source on webmail messages). The only way HTTP is supposed to deliver something base64 encoded is if the source material was base64 encoded. HTTP uses the MIME types just the same as Linux desktop environments do -- to identify the file type, nothing more.

Sure it's possible some wacky configuration may create this situation, but I'd be willing to pull a number out of my tailpipe that says a badly confiugred web server which does bad things is many order of magnitude more probable than is a ftp server which has been misconfigured to use IDENT.

Well, the reason I choose IDENT is the fact that it's still on by default in most FTP daemons (it's not their fault, really, it was a "different time" when they were designed). I'm sure everyone has experienced the MIME type misconfigurations which result in the webbrowser trying to display a file when it's not text/plain. Or the character set encoding problems where the server reports that it's UCS-2, but it's just iso8859-1, or vice-versa. On the other hand, FTP clients sometimes get the wonderful task of trying to deal with the [broken] "DOS" directory format of IIS FTP.

If you enjoy falied downloads, unknowns as to what you're actually downloading (up to 200% (unicode/local conversion) overhead + 33% (base64) of the 200%), inability to resume downloads (with costs up to 199% of the total bandwidth), by all means, continue to believe that HTTP is great for downloads.

I will admit that it is possible for the server to convert the format into Unicode since nothing in the RFC disallows that. The standard gives implementers three choices for the Accept-Charset header, deliver the document in the requested charset, give a 406 error, or deliver an unacceptable charset anyway. It would be a little unusual to see a conversion, however, since most HTTP servers only use it as a suggestion, not a hardline rule, and happily deliver a non-requested format if that's all they have available. Besides, when we're talking about downloads, they're usually a binary file, and converting those would generally corrupt them.

As for the reliability angle, I guess it's been so long that I've had a stable connection that I've forgotten about the frustration of downloading something 4 or 5 times. Not to mention that when I want to download an ISO, I usually look for a bittorrent link instead of an FTP or HTTP site (since resumability is built-in, and it generally uses all of my bandwidth to download). I do vaguely remember using software like GetRight to resume broken HTTP downloads, and I believe I did hate it.

There are a lot of possible downsides to HTTP. The biggest o

Prior Art published Feb 1, 2002 (or 1995)?? by originalhack · 2005-07-03 03:17 · Score: 4, Interesting · on The Grinch Who Patented Christmas

From here.

Make sure you have a good address. If there's any doubt, call the customer or look up the address in an on-line or CD directory.

So, when will we stop issuing patents for using a computer to do EXACTLY the same thing that was previously done without it?

Now, if we'll let Jeff patent using a computer for exactly what was done without it, the 1995 publication of doing exaclty the same thing in the electronic world should act as prior art. From rfc1801

22.4 Bad Addresses If there is a bad address, it is desirable to do a directory search to find alternatives. This is a helpful user service and may be supported. This function is invoked after address checking has failed, and where this is no user supplied alternate recipient. This function would be an MTA-chosen alternative to administratively assigned alternate recipient.

VERY innovative Jeff

Re:Mac OSX has had great IPv6 for a while (10.2)! by Detritus · 2005-07-02 00:01 · Score: 4, Interesting · on Federal Agencies Must Use IPv6 by 2008

Most people, who enjoy semi-anon IP addresses from defacto forced reissue taht I know are against IPv6 and see it for all its regretful faults, despite its wonderful goals and alleged benefits.

The tin foil hat brigade is on the march, again.

If you want an "anonymous" IP address, there is nothing to prevent you from using a sooper-sekret random number instead of the interface's MAC. See RFC 3041.

Re:Not about spam, it's about joe-jobs. by hadaso · 2005-06-25 07:21 · Score: 1 · on IETF Approves SPF and Sender-ID

> ... it will be easy to recognize the email from
> "security@paypal.com" didn't come ebay.

Actually not. Certainly not in the short term. The "From" header field would say "scurity@paypal.com" and this is what the mail program will show to the user. The "Sender" field and envelope-from would show "87i697y098@spammersdomain.oh88769.tld" and would pass both SPF and SenderID tests. To overcome this kind of "problem" one would need a new email client that can show the "sender" field if it is different from the "From", but this would become ineffective because it would be that way for many email messages that are legitimate but have different "sender" and "from" addresses, as both SPF would now require in many cases to allow messages from forwarders, mailing lists etc. to pass the tests. Phishers would adpat immediately!

> There are some long-term implications that allow
> SPF to help in the fight against spam ...
Certainly there are. These are customer lock-in...

Quote from [http://www.ietf.org/internet-drafts/draft-lyon-se nderid-core-01.txt%5D:

In the long run, once the domain of the sender is authenticated, it
will be possible to use that domain as part of a mechanism to
determine the likelihood that a given message is spam, using, for
example, reputation and accreditation services. (These services are
not the subject of the present mechanism, but it should enable them.)

This quote shows exactly what the makers of these standards really want: Services that put harsher limits on their users would be able to gain more reputation. Email recipients would perfer receiving email from these services. Users would migrate to these services. These services would be able to offer very limited services and charge more for more services. Many things that are now possible would become impossible.

f you have your own domain you may publish any range of IP addresses as "authorized to send your mail. But most probably these would be servers shared by many other users, including those that host spy sending zombies that woud be able to send using your address in "from" and capitalize on your "reputation" until it is becomes so low that they move own to using someone else's reputation.

So... users would gradually (or not so gradually) would be forced to give up most of the freedom they now have and prefer a very limited email system just so their email can get through. And all that to support a "standard" that cannot even stop simple phishing attempts!

The problem with SPF is not really SPF. It is understanding what it does and what it doesn't. The only thing SPF does is enabling the owner of a domain to publish a list of IP addresses of servers that may send mail "from" her domain. It only means that mail "from" that domain thatis sent from a server outside this range is certainly forged, at least from the point of view of whoever controls the DNS records for that domain. But IT DOES NOT MEAN that email with an email address with that domain coming from a server in the published IP range is necessarily not "forged". The quoted paragraph above shows exactly what MS aims at with the "SenderID standard": to put domain owners that do not have complete control on the (shared) servers they use at a disadvantage, by making their mail system unreliable. To be 100% reliable you'd need to either be an organization big enough to have its own mail servers that do not route through an ISP, or you'd have to give up using your own domain and instead use an email address from a service big enough to run their own servers. (Running a server on a PC at home on a broadband connection doesn't count as "your own server". Even if it is configured to deliver directly out, the ISP might route all outgoing SMTP traffic through their server, so you would have to include that in your SPF record, and get the reputa

A better way to include calendars by epeus · 2005-06-25 06:44 · Score: 1 · on Microsoft To Extend RSS

There was a demonstration of extended RSS processing that the Microsoft IE team did regarding a calendar. Dare Obasanjo explains:

Dean then started to talk about the power of the enclosure element in RSS 2.0. What is great about it is that it enables one to syndicate all sorts of digital content. One can syndicate video, music, calendar events, contacts, photos and so on using RSS due to the flexibility of enclosures.

Amar then showed a demo using Outlook 2003 and an RSS feed of the Gnomedex schedule he had created. The RSS feed had an item for each event on the schedule and each item had an iCalendar file as an enclosure. Amar had written a 200 line C# program that subscribed to this feed then inserted the events into his Outlook calendar so he could overlay his personal schedule with the Gnomedex schedule. The point of this demo was to show that RSS isn't just for aggregators subscribing to blogs and news sites.

Now, being able to subscribe to an event calendar is very handy, but there is a much simpler way - using hCalendar and Brian Suda's x2v calendar parsing tool.
I adapted the conference calendar page, to add an "hevent" to each session ( with help from Ryan and his hCalendar creator).

Now you can subscribe to it directly using the x2v link. This is available today, not in a future release of IE, and you can easily add events to your blog or webpage this way for people to subscribe to. (from my blog)

Re:Did IETF change their mind? by gtwilliams · 2005-06-25 02:25 · Score: 1 · on IETF Approves SPF and Sender-ID

You may be interested in another point of view on this:

To: spf-announce@v2.listbox.com
From: wayne@schlitt.net
Date: Fri, 24 Jun 2005 17:15:33 -0500
Subject: The IETF has accepted the SPF specification for RFC status!

Sender Policy Framework (SPF) News
by Wayne Schlitt, June 24, 2005

Greetings!

The IETF has accepted the SPF specification for RFC status!

A little over a month ago, we restarted this spf-announce mailing list
with a few updates of what had happened in the last year. Since
then, we have been hard at work on several things, and the first to
bear fruit is the SPF specification.

This SPF specification aims to clearly define the semantics of SPF,
based on the older SPF specifications from late 2003 and early 2004,
taking into account the state of SPF implementations and making
adjustments that have been requested by the IETF. This latest SPF
specification has undergone considerable review, not only by the SPF
community, but also by various IETF groups.

On June 6th, we submitted the completed draft for consideration by the
IETF, and today, the IETF has voted to accept the SPF specification as an
"Experimental" RFC[1]. The SPF specification still needs to go through the
RFC Editor, and this can take weeks or even months to complete.
(There are currently around 300 draft RFCs in the editor queue.)

We had asked for consideration as a "Standards Track" RFC rather than
"Experimental", but the IETF has informed us that they would only
consider "Experimental" status[2]. This was not a big surprise, but we
were surprised at some of the other actions that they took.

The IETF has decided that the SPF specification can not be made into
an RFC until the Sender ID specification is also ready. This appears
to be in order to be 'fair' to Microsoft[3]. Moreover, the IETF has
declared that the last 1.5 years of SPF deployment will not count
toward the two year requirement for experimental testing that they
have set. Again, this is to be 'fair' to Microsoft since their
testing has barely begun.

The Sender ID specifications call for the reuse of SPF version 1
records in incompatible ways in conflict with the SPF specification.[4]
We have made our objections clear to the IETF, but so far, the IETF
appears to be ready to bless this abuse of SPF records.[5] We will
continue to work to try and make SPF as reliable as possible.
__________________

[1] https://datatracker.ietf.org/public/pidtracker.cgi ?command=view_id&dTag=12662&rfc_flag=0

[2] http://thread.gmane.org/gmane.mail.spam.spf.counci l/312

[3] http://thread.gmane.org/gmane.mail.spam.spf.counci l/314

[4] http://www.schlitt.net/spf/spf_classic/draft-schli tt-spf-classic-02.html#anchor6

[5] http://thread.gmane.org/gmane.mail.spam.spf.counci l/333

Re:Did IETF change their mind? by pyrrhonist · 2005-06-24 09:36 · Score: 2, Informative · on IETF Approves SPF and Sender-ID

Which still doesn't really explain why they're conducting the experiment.

They aren't, "conducting an experiment". The draft was submitted as "experimental".

The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution.

To ensure that the non-standards track Experimental and Informational designations are not misused to circumvent the Internet Standards Process, the IESG and the RFC Editor have agreed that the RFC Editor will refer to the IESG any document submitted for Experimental or Informational publication which, in the opinion of the RFC Editor, may be related to work being done, or expected to be done, within the IETF community. The IESG shall review such a referred document within a reasonable period of time, and recommend either that it be published as originally submitted or referred to the IETF as a contribution to the Internet Standards Process.
If (a) the IESG recommends that the document be brought within the IETF and progressed within the IETF context, but the author declines to do so, or (b) the IESG considers that the document proposes something that conflicts with, or is actually inimical to, an established IETF effort, the document may still be published as an Experimental or Informational RFC. In these cases, however, the IESG may insert appropriate "disclaimer" text into the RFC either in or immediately following the "Status of this Memo" section in order to make the circumstances of its publication clear to readers.

Unless MS have pressured them into it, so they can get a crack at declaring Sender-ID as the de facto standard and thereby sidestepping the standards process, of course. That might explain it.

They aren't "sidestepping" the standards process. An "experimental" designation is part of The Internet Standards Process, but is not on the standards track.

Re:Microsoft "Breaks" RSS by leighklotz · 2005-06-24 08:53 · Score: 1 · on Microsoft To Extend RSS

> The RSS standard itself allows for extensions.
>The extensions themselves can be standardized.
There is no RSS standard. There is no standards oragnization, or even industry consortium like the W3C, that defines it. If you don't like RSS 1.0 or 2.0, just declare an RSS 3.0 (or RSS 3.14159) and publish your own spec.

Check out Atom, though; it is being hammered out in the IETF, so at least there is some process for defining it, and a single point of coordination makes it possible to believe you know what someone means when they say it.

There is no "Experimental Standard" by pyrrhonist · 2005-06-24 08:13 · Score: 5, Informative · on IETF Approves SPF and Sender-ID

According to the records in the IETF's database (here and here), both the SPF and Sender-ID anti-spam proposals were tentatively approved by the IESG (the approval board of the IETF) as experimental standards.

There is no such thing as an "experimental standard". The term "experimental" is a "non-standards track maturity level".

See "The Internet Standards Process":

Not every specification is on the standards track. A specification may not be intended to be an Internet Standard, or it may be intended for eventual standardization but not yet ready to enter the standards track. A specification may have been superseded by a more recent Internet Standard, or have otherwise fallen into disuse or disfavor.
Specifications that are not on the standards track are labeled with one of three "off-track" maturity levels: "Experimental", "Informational", or "Historic". The documents bearing these labels are not Internet Standards in any sense.

The IETF has NOT approved either SPF or Sender-ID as an Internet Standard.

Re:Damn if they don't, damn if they do... by jonabbey · 2005-06-23 07:03 · Score: 1 · on Hotmail To Junk Non-Sender-ID Mail

2.2 Source Code Distribution You also have subject to section 2.4 and Your grant of licenses in accordance with Section 2.3,, a perpetual, non-exclusive, royalty-free, nontransferable, non-sublicenseable, personal, worldwide license to distribute or otherwise disclose source code copies of such Licensed Implementation licensed in Section 2.1 only if You (i) prominently display the following notice in all copies of such source code, and (ii) distribute or disclose the source code only under a license that is placed in close proximity to the following notice and does not include any other terms that are inconsistent with, or would prohibit, the following notice:

" This source code includes an Implementation of the specifications entitled " Purported Responsible Address in E-mail Messages", file name draft-lyon-senderid-pra-00.txt, and located at the following link on November 16, 2004, url: http://www.ietf.org/internet-drafts/draft-lyon-sen derid-pra-00 and the specification entitled "Sender ID: Authenticating E-mail", file name: draft-lyon-senderid-core-00.txt, url: http://www.ietf.org/internet-drafts/draft- lyon-senderid-core-00 . In the context of developing those specifications at the IETF, Microsoft submitted a patent disclosure which can be found at http://www.ietf.org/ipr.html. "

For clarification, this Agreement does not impose any obligation on You to require the recipients of Your source code implementations of such Licensed Implementations to accept this or any other Agreement with Microsoft. Your End Users may use the Licensed Implementations licensed in this section 2.2 or in section 2.1 that they receive directly or indirectly from You without executing this Agreement. This Agreement will be available to all parties without prejudice.

Right. What that means is that MS won't require you to check the driver's license of anyone who downloads your software implementing SenderID, but it does mean that the people who download it from you don't have the right to furhter redistribute your code, and they don't have the right to work on it.

That's precisely what the non-sublicenseable bit is about. They don't mind if people write implementations against the SenderID patent, but they'll be damned if those implementers get the benefit of open source network effects to drive improvements and adoption without going begging to Microsoft at each step along the way.