FIDO #2

Gang...

My meeting with Stina roused my curiosity about FIDO, so I spent 
a few hours this morning browsing the recently published specs.

My takeaway is that the FIDO project has a number of problems. 
Mostly, It tries to do so much that it runs into some hard-to-
avoid trouble.

For example, it's all about authentication devices, whether 
external (a Yubikey) or built-in (a fingerprint reader). Any/all 
of these need to be "certified" and "registered" with the FIDO 
Alliance to be used... and they must contain an "attestation 
key" to assert their identity. But those keys cannot be unique 
or they allow cross-site tracking.  (Referred to it as 
"linkability" in the FIDO docs.)  To solve that problem, large 
batches of authentication devices will all carry the same 
attestation certificate.  This prevents a site from being 
"sure" who the user is.  (But, of course, it does allow the 
universe of possible "who's" to be substantially narrowed.)

(Stina talked about there being pools of 5,000 devices all 
having the same key, and I didn't understand what she was 
talking about then.  Now I do.)

But then, if there are large pools of identical-certificate 
devices, there's a concern about the cloning of authentication 
devices.  So each authenticator must have a monotonically 
increasing counter, and increment the count per use. Then 
"Relying Parties" (websites or their FIDO backends) keep track 
of the most recent count seen per user... as a means of 
detecting authenticator clones which will produce a non-expected 
count.

As you can see, a lot of this has become somewhat overgrown.

Also, unless I missed some parts, the specifications, multi-
document and large though they are, seem to be incomplete. I 
don't think it would be possible to implement FIDO based upon 
what's been published.  And, this might even be deliberate...

Then, in a February 12th, 2014 article about FIDO, I saw:

> The draft FIDO specification is open to review but the
> middleware security technology developed out of it is not
> open source but proprietary to vendors such as Nok Nok Labs,
> whose chief exec is ex-PGP Corporation chief exec Phil
> Dunkelberger.
> 
> Nok Nok Labs recently announced a partnership with PC vendor
> Lenovo to pre-install its client software on PCs. The FIDO
> Alliance has grown from six to almost 100 members since its
> launch in February 2013. Recent Alliance members include
> Salesforce, ARM and Dell. Microsoft, RSA and Nok Nok Labs
> all have representatives on the FIDO Alliance board.
> 
> One authentication vendor privately told El Reg that it was
> reluctant to sign up to the FIDO Alliance because of its
> perceived domination by Nok Nok Labs. Exposing its own patent
> portfolio in signing up to the FIDO Alliance and potentially
> restricting the ability to compete with Nok Nok in selling
> authentication server software and other middleware were
> among the other issues for the vendor, who relayed these
> concerns on condition of anonymity.

One of the things Stina mentioned was that the FIDO software was 
SO COMPLEX that Nok Nok Labs was the only participant that had 
gotten it to work... because the spec mostly came from them.

So what would their motivation be to create a detailed 
implementation specification effectively based upon their 
proprietary working solution?  They want to SELL theirs.

>---------------------------------------------------------------

So, the 1000-foot view appears to indicate that FIDO is about 
making money and/or protecting turf... with complex, closed-
source, proprietary solutions... and that the COMPLEXITY of the 
system plays into the entrenched interests of at least some of 
the participants.

SQRL's obvious advantage is that it's not about anyone making 
money. It's about building the simplest solution that will do 
the job... and being as open about every aspect of it as 
possible.

Somewhat sobering, though, is that this DOES mean there are now 
some corporate interests that have an active vested interest 
against anything that's not FIDO.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/22/2014 4:17:10 PM
grc.sqrl 459 articles. 0 followers. Follow

8 Replies
895 Views

Similar Articles

[PageSpeed] 47

On 2014-02-22 8:17, Steve Gibson wrote:
[...]
> But then, if there are large pools of identical-certificate
> devices, there's a concern about the cloning of authentication
> devices.  So each authenticator must have a monotonically
> increasing counter, and increment the count per use. Then
> "Relying Parties" (websites or their FIDO backends) keep track
> of the most recent count seen per user... as a means of
> detecting authenticator clones which will produce a non-expected
> count.

FIDO's approach strikes me as very reminiscent of DRM for some reason.

Regards,
Sam
0
Sam
2/22/2014 6:22:48 PM
[see above post(s) for full context]
In grc.sqrl, Steve Gibson wrote ...

> Somewhat sobering, though, is that this DOES mean there are now 
> some corporate interests that have an active vested interest 
> against anything that's not FIDO.

We need to get SQRL out in front as quickly as possible.  If 
SQRL can build a sizable lead it may become the de facto 
solution.  I don't want to see the world saddled with something 
as odious as FIDO appears to be in its current form.

-- 
Terry //
0
Terry
2/22/2014 7:57:46 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mBjcORp4kXq7AiN3dUAdEvKo5xkjipTgU
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 22.02.2014 20:57, schrieb Terry L. Webb:
> We need to get SQRL out in front as quickly as possible.

I don't think that this should be a high priority for us, because
rushing out something is a recipe for disaster and certainly does not
improve the quality and/or security of a product/protocol.

In my understanding it will take at least one fully working prototype
(with a couple of implementations for testing interoperability and such)
before there is actually something that is ready for the mass market.
And we are still away quite a bit from this "milestone".

Best regards,
Karol Babioch


--mBjcORp4kXq7AiN3dUAdEvKo5xkjipTgU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTCRA5AAoJEHSaZc1HnzIVqIQP/j+UyHT9rFohvsLvghRrHans
IEpRdn5yNqpHTGS+/OlQsMtHtoJCWTruS5M1Sd8bB4t7Fy7IZuUVHB1wxfXxmeGE
O9hO2AkXQeQm7E2WlDD/eccKgl/g/Pqv/bCqLFvQZCx/6FBpgNWZRazQPTu3qHPs
denmnR//kRKKuLU//bZmb0qf0KRwXCqKh30Cv/3FSmekli7lbgLwOOv3nGRdyE1l
gT2fBwlxgS3grzgdUZzL6/JQeLMAA+NSmuR8j7ZNi2ALJ2WJEFLRJup2mT/LWFgB
NJSTtgE0oqn9lNKHsW2/VN6ishDiUTgw7lsDdDz57rmZUAmXvwP1++2rkSG94G5K
xc7QF6X1cUKDYNIke5MBzMi2mQu/fAdrubZFjKf55eM0Z0otkTH8S5WNP9QgI/iz
dz79wokMnZYw74MkROG6a3hoUS/TVVa2WyIdQeMtXFpx1MV0oLmp+/O64dkoiVW+
QiFc+NX3LHL4rld3uB/ioDUMxd3CUO94c8QrnPhmi+ycp7HF8mNGn1p9tEsiR8ZS
uXIkDU0bkwnQkCHkuG0bf1A1VOvGY0WLxos01TjwUSc/5hyUq77t0F53j+6disoS
9vzsyJh55zn0XMoYBhI1v4CJhz7bm93XFRn008coSPBJFInv/ekU27Q5dLP6VNNF
eq75Z9mhf3N0RMup7wut
=GGTn
-----END PGP SIGNATURE-----

--mBjcORp4kXq7AiN3dUAdEvKo5xkjipTgU--
0
Karol
2/22/2014 9:01:42 PM
In grc.sqrl, Karol Babioch wrote ...

> Am 22.02.2014 20:57, schrieb Terry L. Webb:
> > We need to get SQRL out in front as quickly as possible.
> 
> I don't think that this should be a high priority for us, because
> rushing out something is a recipe for disaster and certainly does not
> improve the quality and/or security of a product/protocol.
> 
> In my understanding it will take at least one fully working prototype
> (with a couple of implementations for testing interoperability and such)
> before there is actually something that is ready for the mass market.
> And we are still away quite a bit from this "milestone".

I don't mean rush it out the door.  However, once it's ready to 
go we need to get it out in front as quickly as possible; get 
sites to adopt it so that users will have places to use the 
clients.

Besides, Steve never rushes development, it's not in his DNA.

-- 
Terry //
0
Terry
2/22/2014 9:58:10 PM
[for the unabridged version, see Terry L. Webb's post above]

> Besides, Steve never rushes development, it's not in his DNA.

That's true.  I only have one speed.  So all I can do is remain 
focused upon it and have it done as soon as it can be.

The BIGGEST waster of time would be needing to go back and fix 
something that was wrong, so if moving forward carefully is able 
to minimize that, that's probably useful.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/23/2014 6:17:48 PM
In grc.sqrl, Steve Gibson wrote ...

> [for the unabridged version, see Terry L. Webb's post above]
> 
> > Besides, Steve never rushes development, it's not in his DNA.
> 
> That's true.  I only have one speed.  So all I can do is remain 
> focused upon it and have it done as soon as it can be.
> 
> The BIGGEST waster of time would be needing to go back and fix 
> something that was wrong, so if moving forward carefully is able 
> to minimize that, that's probably useful.

One of my favorite sayings is "Measure twice, cut once", which I 
learned from my grandfather who was a carpenter, perfectly 
describes your style of problem solving.  :)

-- 
Terry //
0
Terry
2/23/2014 8:17:24 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--JmL64D0leiQtIDW8xIVr4TnOoJLJFPdIq
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

finally I spent some time going through most of the available
specifications of the FIDO alliance for myself. In the following post(s)
I want to share my opinion, because I do think that Steve misrepresented
some aspects of the whole thing and/or didn't shine a light on the
"side" of the story, especially when it comes to U2F, which I will cover
later on in the appropriate post itself. I'm in no way connected to
FIDO, Google or anyone else in the authentication business

Am 22.02.2014 17:17, schrieb Steve Gibson:
> For example, it's all about authentication devices, whether=20
> external (a Yubikey) or built-in (a fingerprint reader). Any/all=20
> of these need to be "certified" and "registered" with the FIDO=20
> Alliance to be used... and they must contain an "attestation=20
> key" to assert their identity.

To my understanding any "authenticators" need to be certified, which
basically comes down to putting an attestation key into them. The
attestation infrastructure can then be used by the relying party to
allow only specific devices, e.g. a bank could choose to accept only
devices from a specific vendor. This in itself is probably not that bad
of an idea, because a consequence of having an open specification is
that there could potentially be a lot of bad/insecure implementations.

This is also a problem for SQRL. I really do like the openness of your
approach, but all of this means also that it is comparatively easy for
bad guys to come up with an evil SQRL client stealing the master key(s)
of people.

Registration in the FIDO specs on the other hand is something happening
only between the user and the relying party (RP) and you should be very
careful with this term as it is used consequently whenever they are
referring to the association of key material with a user and has nothing
to do with the certification itself.

> But those keys cannot be unique
> or they allow cross-site tracking.  (Referred to it as
> "linkability" in the FIDO docs.)  To solve that problem, large
> batches of authentication devices will all carry the same
> attestation certificate.

> (Stina talked about there being pools of 5,000 devices all
> having the same key, and I didn't understand what she was
> talking about then.  Now I do.)

Interesting. The specification talks about batches of 100k (though it is
only an example). Obviously enough, it could still be possible to track
people if this number is too small and the datasets are big enough.
Maybe something not to big of a problem today, but in the future?

> But then, if there are large pools of identical-certificate
> devices, there's a concern about the cloning of authentication
> devices.  So each authenticator must have a monotonically
> increasing counter, and increment the count per use.

The counter is a consequence of the fact that hardware devices are not
necessarily required to be certified and that software implementations
are allowed, too. Bad implementations (or software implementations in
general) might get compromised / cloned. The counter is a potential way
for detecting this. At least in theory.

I'm not entirely sure how this is supposed to work in practice. The
counter is allowed to count either the use of single key-pairs for a
specific origin, batches of key-pairs and/or even the global use of any
key pair. Furthermore the counter is allowed to wrap around -
effectively starting over at zero. All of this means that you probably
can't take the counter at face value, but have to work with some sort of
margins, making it prone to cloning again. I'm not convinced by all of
this. On the other hand anyone with "real" demands for security will
probably require the user to have a certified device anyway, rendering
this aspect of FIDO quite useless - at least in my eyes ...

> Also, unless I missed some parts, the specifications, multi-
> document and large though they are, seem to be incomplete. I
> don't think it would be possible to implement FIDO based upon
> what's been published.  And, this might even be deliberate...

> One of the things Stina mentioned was that the FIDO software was
> SO COMPLEX that Nok Nok Labs was the only participant that had
> gotten it to work... because the spec mostly came from them.

I cannot comment on this. A lot of specification / documentation is
available, but all of this is still marked as "draft". I'm not sure
whether you gain access to additional documents and/or input from the
other members once you actually join the alliance or anything like that.
Implementing it based upon the available documents right now, would
probably be quite hard.

> They want to SELL theirs.

Granted, at the end of the day FIDO is about selling hardware (though at
least U2F is allowed to be implemented in software, too). I don't think
that this is a bad thing, though. I *really* do think that implementing
this kind of crypto in hardware and denying any access to the key
material itself is a good idea (though open hardware/software would be
great). As a consequence there will be people making money out of it.
Personally I'm fine with this, but I can see why people don't like the
idea and there is definitely space for abuse here. The way Nok Nok Labs
was described in your posting indeed raises some concerns. I guess we
will have to see how all of this works out in the end.

Best regards,
Karol Babioch


--JmL64D0leiQtIDW8xIVr4TnOoJLJFPdIq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTC3bXAAoJEHSaZc1HnzIVC2YP/iemfGi8PK9CpgQ6h4afkX+X
cnmKaT+QDkg3i2xdXPW5iVWrTeKsBtB47G6RtIrho76G71q4Vl4dIVDIMkb6K5b/
mJGm2Rblz/+MAiZsWnzhEv9k6ohSKYOCVnCp+BU6W4DrgaIRip8rrTX4tC9hAgtU
2sDi2sFZmgnFSlhus2yUvax5CBrJfl9dzyu1Fltch1JUfR92s1FtoCfgvPBUwIcQ
3I3aj/Op4AU5fPkQCPajn+gF+XeHWLBVjHwpz7Op/o/deC7b6YzCNt0/v4ocgNdk
om+EcOL/zfa3V3LuSOj9bIl1biexo4m9CkxbiWfQ6f/IQnBV4bBwCsPkF1PWnMwi
5nNuKOi4v79aq2AtkJeHULHzpJw+NJ7OegRB8oALUHCju6eBTErMLCyHvmWGQbmP
MwRq7W4gg3HUrJtNkwBFyfXLKernqMEaTwOtedK3w66YGI2kbUZGzzQs2ScuLJzG
mrLUvcitqX/hGQnckuXvWDDmKSv9ir1zwyjvF5U0li2cJJRJmR2zGjHbHCVXGTxB
wmQExk+6vR2AKBhqykclGmhTqGaWC7x/jjW3uHRfCs8p4N0gZdFgDgcAibEgpzRU
c/KzKBkTR2mSmjL6bUJfJFSrQNbzFXndhNeZI2gw0CpVQUJB78FvtALW27qnTK90
owoRSs1TZ1TFLHYvX3rX
=HhBw
-----END PGP SIGNATURE-----

--JmL64D0leiQtIDW8xIVr4TnOoJLJFPdIq--
0
Karol
2/24/2014 4:44:06 PM
[for the unabridged version, see Karol Babioch's post above]

> Hi,
> 
> finally I spent some time going through most of the available
> specifications of the FIDO alliance for myself. In the following
> post(s) I want to share my opinion, because I do think that Steve
> misrepresented some aspects of the whole thing and/or didn't shine
> a light on the "side" of the story, especially when it comes to U2F,
> which I will cover later on in the appropriate post itself. I'm in
> no way connected to FIDO, Google or anyone else in the authentication
> business

I'm glad you spent some time with the FIDO information, Karol, 
the more eyes on it, the better.  And I don't disagree with 
anything you wrote so far... though it sounds like the parts
you were taking issue with most in what I wrote you haven't
yet detailed, so we'll wait for that.  :)

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/24/2014 5:05:55 PM
Reply:

Similar Artilces:

4.2.2.2
Occasionally I will get an alert from ZAF announcing "The firewall has blocked local network access to 4.2.2.2 (DNS) from your computer." The explanation says that ZA has blocked access to Port 53 on a DNS server. Why would ZA block this? As far as I know, it has never requested permission to access this server and I have never denied such permission. I use a Netgear router, and in order to make it work with my system, I was instructed to configure the DNS Configuration of the TCP/IP Properties of my network card and add 4.2.2.2 as one of my DNS Servers. Thanks for you...

SeaMonkey 2.2 #2
I have just re-installed 2.0.14 and it works a treat. Don't mess with wot ain't broke. D. ...

2 #2
Name: Argenis Email: mechanical_rockstar_at_hotmail.com Product: Firefox 2 Beta 2 Summary: 2 Comments: i'm mexican Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2 ...

2 #2
Name: heldernda silva Email: shelder67atyahoodotcodotuk Product: Shiretoko Summary: 2 Comments: 3 Browser Details: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 From URL: http://hendrix.mozilla.org/ Note to readers: Hendrix gives no expectation of a response to this feedback but if you wish to provide one you must BCC (not CC) the sender for them to see it. ...

2 #2
Name: woooooooooolf Product: Firefox Summary: 2 Comments: ПЕЗДАТЫЙ БРАУЗЕР , СУККА! И ПОЧТОВОЙ КЛИЕНТ ПЕЗДАТЫЙ! В томже духе ебаште и мы парабатим ээтот мир , када все будут юзать , мы пашлём им тройан ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 ...

2-2
Name: pepe_writer@hotmail.com Email: pepe_writerathotmaildotcom Product: Firefox Summary: 2-2 Comments: 22 Browser Details: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.173.1 Safari/530.5 From URL: http://hendrix.mozilla.org/ Note to readers: Hendrix gives no expectation of a response to this feedback but if you wish to provide one you must BCC (not CC) the sender for them to see it. ...

upgrading from 2.16.2 to 2.20.2
Hi, I have Bugzilla 2.16.2 installed on RedHat 9, which is working fine. I want to upgrade to 2.20.2. I am using the tarball method mentioned in the bugzilla upgrade guide. bash$ tar xvf bugzilla-STABLE.tar bash$ cd bugzilla-2.20 bash$ cp ../bugzilla/localconfig* . bash$ cp -r ../bugzilla/data . bash$ cd .. bash$ mv bugzilla bugzilla.old bash$ mv bugzilla-2.20 bugzilla after this I tryed to run ./checksetup.pl. at last it gives the following error ---------------------------------- If you want to see pretty HTML views of patches, you sho...

Has anyone gone from 2.16.2 to 2.18.2 and then 2.22?
We have been able to go from 2.16.2 to 2.18.2 but now we need to get on 2.22. Does anyone have any tips we should keep in mind as we do this. BTW our MySQL is 4.1 Thanks, David Go for it. As long as you haven't customized Bugzilla, there shouldn't be any issues. Keep in mind, however, that as a general rule, I am a pessimist about software changes, no matter who wrote the software, especially if it's M$: "Blessed is the pessimist for he'th made backups." :) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator ...

iManager 1.2.2 to 2.0.2 Upgrade
I've been running GW 6.5 WebAccess on the following system configuration: Netware 6.0 SP4 eDirectory 8.7.3 SP2 IR JVM 1.4.1 SP6 Novell Enterprise Web Server Tomcat 3.3 Apache 1.03 iManager 1.2.2 Yesterday I made the following change: Upgraded iManager to v2.0.2 and Tomcat to v4.0. This change broke GW WebAccess. I'm getting the following error when I try to get into GW WebAccess. It appears to pop up as it tries to bring up the login page. Server Error This server has encountered an internal error which prevents it from fulfilling you...

Will migration from 2.1.2 to 2.2 be possible?
Hello, I was wondering if there will be plans to easily migrate from DNN 2.1.2 to DNN 2.2? I say easily because some people run thousands of portals on 1 DNN system. There should be an easy way to automatically migrate from old DNN to new. Is there going to be plans to allow this? If so, how will it work? Will any downsides exist? How about existing 2.1.2 skins and modules. Will they all work in DNN 2.2? How about the user model. Does that change in DNN 2.2? Right now its 1 username for the entire DNN server. Does DNN 2.2 have usernames unique to portals? If so, how w...

Security Advisory for Bugzilla 2.18.5, 2.20.2, 2.22, and 2.23.2
Summary ======= Bugzilla is a Web-based bug-tracking system, used by a large number of software projects. This advisory covers six security issues that have recently been fixed in the Bugzilla code: + Sometimes the information put into the <h1> and <h2> tags in Bugzilla was not properly escaped, leading to a possible XSS vulnerability. + Bugzilla administrators were allowed to put raw, unfiltered HTML into many fields in Bugzilla, leading to a possible XSS vulnerability. Now, the HTML allowed in those fields is limited. + attachment.cgi could leak the n...

Filters not working in 2.2 #2
Since I updated to 2.2 My filters are not always automatically sorting incoming email. They sort some but not most of the messages. If I run the filters manually they work as expected. They are all set to "Checking Mail or Manually Run". ...

Firefox 2 RC 2 #2
Name: Simon Product: Firefox Summary: Firefox 2 RC 2 Comments: I like the product, but I would like to see: -More colour for the icons of the 2.0 default theme (the glow effect is not enough), -Smaller tabs like in Firefox 1.5 (the tab bar is too large), -A fast access to the recently closed tabs in the tab bar button like for open tabs instead of just in the History menu. Thanks! Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061003 Firefox/2.0 ...

Log Parser 2.2 #2
followup to grc.techtalk Log Parser 2.2 http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&DisplayLang=en ----------------------------------------------------------- Quote ----------------------------------------------------------- Quick Info File Name: LogParser.msi Download Size: 1444 KB Date Published: 4/20/2005 Version: 2.2.10 Overview Log parser is a powerful, versatile tool that provides universal query access to text-based data such as log files, XML files and CSV files, as well as key data sources on the Windows� operat...

Web resources about - FIDO #2 - grc.sqrl

Mobile phones, plans and more reasons to love Fido - Fido.ca
Fido offers unlimited plans starting at $20, great phones at $0 and more with the Fido ADVANTAGE - Billing by the second, FidoDOLLARS, FidoTRADE, ...

Il pastor fido (Handel) - Wikipedia, the free encyclopedia
It was composed in 1712 and first performed on 22 November of the same year under the composer. The opera opened to a largely hostile reception, ...

Austin Fido (@canetop) on Twitter
Log in Sign up You are on Twitter Mobile because you are using an old version of Internet Explorer. Learn more here Austin Fido @ canetop Football ...

La Nuova Musica: G.F. Handel: Il Pastor Fido (1712) - world premiere recording - YouTube
G F Handel IL PASTOR FIDO (1712) world premiere recording Libretto based on original by Rinnuccini Cast Amarilli: Lucy Crowe - Soprano Mirtillo: ...

It's all right, Fido, I know exactly how you're feeling
Any dog owner will claim they can tell exactly what their pet is feeling just by looking at it. Scientists now say they may well be right.

It's all right, Fido, I know exactly how you're feeling
Any dog owner will claim they can tell exactly what their pet is feeling just by looking at it. Scientists now say they may well be right.

It's all right, Fido, I know exactly how you're feeling
Any dog owner will claim they can tell exactly what their pet is feeling just by looking at it. Scientists now say they may well be right.

Fancy Fido the Quoll for a pet?
Quolls and other small native mammals could make great domestic pets - every bit as enjoyable as cats, dogs and rabbits - with revenue from sales ...

Fido, Rogers to offer iPhone with 3-year contracts
Fido joined parent carrier Rogers Communications on Thursday in offering the iPhone in Canada in July, but was equally silent on pricing and ...

Subaru working to protect Fido
Driving with pets - either to the park for daily walks, or on longer trips to the cottage or beyond - is common. And although pets are considered ...

Resources last updated: 1/19/2016 7:54:00 AM