[EIDXA] VU7 info and an interesting LOTW thread

[Glen and Pam]

Hi all,

I wrote W0GJ about 2 weeks ago.  Listed below is info on his upcoming activity to VU7.  Also, below that is an email from my son Grant K1KD with an interesting thread regarding some of the history of LOTW.

73,
Glen K0JGH


Happy New Year!!

I leave Saturday and arrive in Cochin, India Tuesday midnight.   The 
boat leaves Jan 12.  We will be QRV at 1830Z Jan 14.   We will have 
about 12-14 stations QRV from four separated islands.   ....and we will 
be LOOKING for NA!!!!!

73!

Glenn


*******************************************************************************************************************************************************************

Dad,

With permission from WC1M, I am enclosing his thoughts about LOTW as was posted on the YCCC reflector last week. Feel free to distribute to EIDXA as you wish. 73, Grant

1/1/2007
I usually refrain from commenting on LoTW because I was involved in its
creation. But some interesting things have been said on the YCCC reflector
about it, and I'd like to add a few observations of my own:

1. I'm certainly biased in LoTW's favor, and upload all of my QSO records to
it. I check my confirmations and award status regularly. That's not to say
I'm 100% happy with it, but I do think it's a good thing. I don't see how
anyone can say nobody uses it when over 14,000 users with over 20,000 call
signs are registered, over 100 million QSO records have been uploaded and
over 7 million QSLs have been generated. True, a lot of the records are from
contest logs, but there's nothing wrong with that because it potentially
reduces the burden of millions of automatically-generated QSL cards on the
overstrained and increasingly expensive buro system.

2. LoTW was never intended to replace paper QSL cards, and never will. The
idea was to provide a faster, more reliable and less expensive route for
confirming large numbers of QSOs when the paper card is not needed or
desired. For example, I like to have at least one paper card for each DXCC
entity that I confirm. I keep them in a set of special binders that people
can page through when they visit the shack. I also like to give my kids the
envelopes and stamps I get from exotic countries. But I don't need or want a
separate paper card for each band-mode confirmation, and I certainly don't
need or want paper QSL cards for the thousands of contest QSL requests I get
from entities I already have confirmed. LoTW allows me to confirm each and
every one of the thousands of QSOs I make in a major contest weekend in a
matter of seconds, without having to spend hours printing labels, handling
cards, paying high outgoing buro prices, etc.

3. As the development team and ARRL management can tell you, I pushed
relentlessly for tight security (as did Ted.) I was fully aware at the time
that this would make LoTW less convenient to use, particularly when it came
to applying for a new certificate (the technical term for that is
"authentication".) But as Ted said, it was crucial to protect the integrity
of the DXCC program, which is the premier DX awards program in amateur
radio. There's ample historical evidence that a small minority of
malcontents will try to game or bust the DXCC program, and would find LoTW
an irresistible target. We ran attack scenarios for many levels of security,
from lax to very tight, and found that there were a lot of loopholes in
simple password-based systems and systems that use weak authentication. My
feeling was that if someone got DXCC credit without actually earning it, the
DXing community would lose faith in LoTW and it would be next to impossible
to regain their trust. In the end, the most persuasive argument was that we
could start out with tighter security, then relax it over time if the system
proved too cumbersome. We couldn't do it the other way around.

4. Much of the LoTW design was implemented well (I didn't have anything to
do with that.) The website is particularly well done. The main usability
issues are in TQSL and TQSLCert. My belief is that most of these problems
stem from terminology which is overly-technical or obscure (it's not even
clear to me that users need to know what a "certificate" is, even if a full
PKI system is used.) In addition, the user interfaces aren't particularly
intuitive, error messages are not informative enough, and the Help system is
sparse. There are also some issues with backing up certificates, renewing
certificates, and recovering from errors during those procedures. I believe
most of those problems could be fixed by implementing a few simple
safeguards in the TQSLCert program. The FAQs put out by ARRL are helpful,
but would be needed less if the terminology and interface were more
intuitive, the software was more bulletproof, and the Help system was
better.

5. My original concept of the system was to have the LoTW user interface
implemented in all of the popular log programs. In fact, TQSL and TQSLCert
were to be demo programs. Why implement LoTW in the log programs? Because,
as a long-time DXer and Honor Roll recipient, I was aware that DXers would
not want to duplicate data entry efforts in LoTW and their log program. The
idea was for a user to be able use his/her favorite log program to select
records to upload (including "all since last upload"), click a button,
optionally enter a password to unlock the private key, and poof! -- the
records would be magically signed and submitted to LoTW. This isn't terribly
difficult to do, but apparently none of the leading log programs do it. 

6. I also wanted to see a single-click status update that would retrieve all
unprocessed status information for each uploaded record, such as
"confirmed", "submitted for DXCC credit", "DXCC credit payment required",
and "DXCC credit received". This information would be used to automatically
update the user's log program database. I'm aware of one program that
retrieves status information from LoTW and can use it to update its database
-- XMlog, a terrific freeware logger written by my friend W1ECT (see
www.xmlog.com). However, currently LoTW provides only "confirmed" status
records, despite my repeated requests and pleas over the past several years
for the system to provide the all-important "credit received" status (a poor
excuse has been given for not doing so.) I have personally decided not to
apply for or pay for any LoTW credits until this feature is implemented. I'm
not going to spend the time entering over 1000 new status updates into my
log program -- I'd rather spend the time contesting, DXing or working on my
antennas! I've made this clear to the LoTW team at ARRL, but the notion that
one of the designers won't participate on the revenue side hasn't had the
desired impact. 

7. Even though I'm not using LoTW for awards credit, and am terribly
disappointed about that, I'm still uploading my log records. That's because
more records in the LoTW database will encourage more people to register and
upload their logs. Hopefully, this will lead to greater acceptance (and
perhaps more pressure on ARRL to implement DXCC status downloads!) I
encourage every YCCC member to learn how to use LoTW.

8. FYI, originally TQSL and TQSLCert were to be demo programs for a library
of utility routines to be provided to the log program developers. As far as
I know, the library was created and offered to the log program authors, but
I don't know what else was done to encourage them to implement support for
LoTW. I don't know why so few of them have done it. As a result, TQSL and
TQSLCert became the defacto user interfaces for LoTW.

9. I don't know whether the development team at ARRL doesn't think log
program integration with LoTW is important, or whether they don't have the
budget to work on it any more, or whether they're not getting cooperation
from the log program authors, or all of the above. 

10. If the problem is budgetary, then I think the directors should vote a
little more money for the project in order to refine and complete it. It's
time for Phase II.

Hope this sheds a little light.

73, Dick WC1M



1/1/2007
Sorry, I should have been more clear. My idea was to have LoTW incorporated
into DX logging programs, not contest logging programs. DX logging programs
already have all sorts of facilities for keeping track of QSLs and awards,
so LoTW would fit right it. I agree that full LoTW support really doesn't
belong in contest logging programs. I, for one, import ADIF output from
Writelog into XMlog, a DX logging program which keeps my master log of over
100,000 QSOs. The import takes just a few seconds after a contest. I use
Writelog strictly for contesting, and use XMlog to keep track of QSLs, DXCC,
and other awards. That's the place where I deal with LoTW.

For those contesters like you who don't care about DXCC, a contest logger
could simply allow you to sign and upload the Cabrillo log with a single
click. I was in favor of allowing a single upload like this to also submit
the contest log to ARRL (if it's one of their contests.) One click could do
it all.

Of course it's up to the DX log program authors to implement support for
LoTW. But I figured with a well-designed system, a good library of utility
routines and technical support from ARRL, log program authors would want to
add this important new capability to their list of features. After all, they
go through great lengths to support the DXCC program, which has always been
defined by ARRL.

Finally, LoTW was designed so that other awards sponsors could use the QSL
data under agreement with ARRL. I don't know if there's been any progress on
that front.

73, Dick WC1M


1/4/2007
The one year and three year certificate expiration terms were not part of
the original LoTW design specification, which simply outlined the procedure
for renewing a certificate by signing the request with the existing
certificate (which is why you have to do it before the certificate expires.)
I don't know why one year and three years were chosen. It's typical for
commercial security certificates to expire in one year. But such
certificates usually require re-authentication. The idea is to guard against
damage from the private key being stolen by limiting the time during which
it is valid.

Since LoTW certificates can be easily renewed by whomever has the private
key, without re-authentication, the expiration date doesn't limit damage --
the thief can simply renew the certificate before it expires. This was my
response when asked by ARRL whether I thought it was OK to increase the
validity term. I think some sort of expiration date is good, not so much for
security but as a means for making periodic changes to the certificate
format and/or requirements for using LoTW. Three years is certainly better
than one year. I think five years would be fine.

The LoTW specification offered an alternative scheme in which the
certificate would expire when the license expired. Under that scheme a
renewal request would require a new license expiration date in the FCC
database (i.e., the user would have to renew his/her license in order to
renew the certificate.) 

Of course, this works only for US licensees. That's because very few DX
countries have reliable online license databases. The spec suggested that a
renewal from a DX station with an expired license would have to wait for a
copy of the new license to be mailed to HQ. Unfortunately, the alternative
scheme really isn't feasible for DX stations. Some DX licenses don't show
expiration dates or the dates are not intelligible. Asking DX stations to
mail in yet another copy of their license wasn't an attractive idea, either.

I don't recall all of the reasons why the alternate scheme wasn't adopted.
I'm sure the DX version was a non-starter. Another complication is that LoTW
allows you to have certificates for expired licenses (e.g., your old novice
call.) Assuming that it's generally not a good idea to have any secure
system in which credentials are perpetual, you have to pick an arbitrary
validity term.

I don't recall whether linking expiration with ARRL membership was
discussed, but it probably was. We spent well over a year discussing every
aspect of the system before a single line of code was written. A lot of
ideas like that were debated thoroughly, usually with advocates on both
sides of the question. Believe me, each and every aspect of the design was
carefully considered, and where you see things that aren't perfect, it's
likely that a "lesser of two evils" compromise was made. Anyway, I'm sure
the fact that LoTW and the DXCC program are open to non-ARRL members was one
reason for not linking certificates to membership. My feeling is if there's
a security reason for imposing a term of validity, it shouldn't be bypassed
by ARRL membership (wasn't Don Miller an ARRL member at one time? ;-) If
there isn't a security reason, then it should be extended.

BTW, aside from usability issues, the biggest problem for LoTW is the lack
of reliable online DX license databases. Not only has this made it
impossible to link certificate and license expiration for DX stations, it
has made it impossible to use the simple but elegant US authentication
scheme that relies on the FCC license database and the US Postal Service.
Acceptance of LoTW among DX stations has been slow because many are not
happy with having to mail in a copy of their license (I think in some
countries it may be illegal to photocopy official documents.) Personally,
this is my biggest disappointment with the system. It's nobody's fault and
there doesn't appear to be a good solution short of waiting for those online
DX license databases to appear (don't hold your breath.)

So, you say, why not soften up the security and make it easy for everyone to
register? Well, as I said, we spent over a year analyzing what would happen
if LoTW were to be based on weaker authentication, and the results weren't
pretty. You see, it's not just that people can cheat on their own behalf.
Online systems, unlike paper systems, have the potential for widespread
cheating and/or corruption. It takes a forger a lot of time to fake a single
QSL card, while a determined hacker can fake or corrupt thousands of records
with a single click of the mouse. And it's not just his/her own records --
your records and everyone else's are vulnerable. It's a different ballgame
with computers and online systems. We found all sorts of ways people could
give themselves credits, give others credit (perhaps for money), foul up
awards for others, etc., etc. Another problem with weak security is that a
disgruntled ARRL employee with access to the server, or a hacker who gets
past the firewall, could do things to undermine the LoTW system.

This is why it was decided to digitally sign each and every QSO record,
permanently and indelibly marking it with the signature of the originating
station. Properly implemented, there's no known way those records can be
changed without detection. Hand-in-hand with this is the requirement that
the signature be linked with the person who owns the call sign, which leads
to the need to authenticate that individual. It's not easy to do this with
online systems, and I think LoTW has done the best it can under the
circumstances. It isn't perfect, and it imposes something of a one-time
inconvenience (more so for DX stations), but I think that's a small price to
pay for a  lifetime of benefits. Yes, renewal is inconvenient, but I think
this is something that can be improved without undermining the security of
the system.

[BTW, digitally-signed QSL records allow ARRL to share subsets of the
database with other awards organizations, who would be able to independently
verify the records.]

As I said before, there are many out there who would like nothing more than
to destroy the integrity of the DXCC program to embarrass ARRL. You say it's
only a hobby, but many thousands of hams have collectively spent millions
upon millions of dollars to chase those plaques (towers, antennas, radios,
postage, cards, buro fees, IRCs, etc., etc.) I think it's a little more than
a hobby to them, and you know there would be outrage and outcry at the mere
suggestion that someone could receive credits that are not earned.

Is it impossible to cheat LoTW? I would never claim that, because as Ted
said, we never say that in the security biz. That particular claim is known
as "snake oil". However, I can say that cheating LoTW is a lot harder than
you may think. Go ahead -- see if you can get a cert for BS7, or give
yourself credit for VU7, or give someone else DXCC. Overkill? Maybe. But do
you really want a system that could be filled with unverifiable garbage?

Yes, I agree that LoTW could be made much more usable. But I do not agree
that the primary usability problems are a function of the underlying
security. It's true that the security scheme introduces a one-time
inconvenience and delay during initial registration. But I think some
revisions could greatly improve usability and reduce the ongoing
inconvenience to a minimum. As I said, I believe it's time for ARRL to
allocate resources to a significant LoTW revision. I think we're in
agreement on that.

73, Dick WC1M


1/4/2007
While security was a major objective (that's why Ted and I were brought in),
I think it's going a too far to say that there were no champions for
simplicity. Typically, the dynamic was Ted and me arguing for tighter
security and ARRL staff arguing for greater simplicity and usability. That
doesn't mean we didn't care about simplicity and they didn't care about
security, but there were advocates on both sides. I recall one meeting where
the lead developer and three senior ARRL staff members pushed us very hard
on the need for the license authentication system we proposed. It was only
after the attack scenarios in the appendix were developed that the
authentication scheme was accepted. Again, the key selling points were that
the consequences of attack were pretty bad and that the level of security
could be changed and/or loosened in the future.

That said, I think it's important to separate the convenience/usability
issues in the authentication process from the convenience/usability issues
in ongoing use of the system. It's also important to recognize that the use
of PKI does not require as strong an authentication system as we have.
They're really two separate issues. 

It would be possible to get many of the advantages of PKI with a simple and
instant online authentication scheme. The primary advantages of PKI are: 1)
not vulnerable to password cracking programs, 2) the private key is on the
user's computer only, not at HQ, and 3) (most important) digital signatures
permanently validate each QSO record. My firm belief is that, ignoring
authentication for the moment, the processes of generating/storing a private
key,  getting/renewing a certificate, using the certificate to sign QSO
records, and uploading signed QSO records could be made relatively simple,
transparent and usable by the majority of potential users. The keys are to
hide most of what's going on, use simple and intuitive terminology, provide
superior error handling, and write really good documentation (with examples,
as you suggest.)

That said, there are some issues with LoTW, DXCC, the art of DXing, and
amateur radio licensing that make it very difficult to simplify the process.
For example, a lot of logging programs don't record the QTH from which you
made the contact -- only the other station's QTH. Even for those that do,
users may or may not fill in the information when they move from place to
place. As a result, you could have QSOs from multiple states in your log. If
you just upload them using your current station info, the state will be set
to where you live now. When older QSOs match, the state will be wrong. The
only way around this problem is for you to go through your log, identify
which QSOs were made from where, and use that information to select records
for each QTH for separate upload to LoTW. This is a major pain, but there's
not much the software can do to help (except explain the situation better.)
Hopefully, log programs will include "my QTH" fields in the future and
people will use them.

There are similarly complicated issues with handling expired call signs,
portable call signs, operating with reciprocal permission, call signs that
have been held by multiple individuals at different times, etc. Some of the
issues simply don't have good solutions. All we can do is explain them
better and try to improve the system's ability to detect special cases and
help the user through them.

Now let's look at the authentication scheme. Clearly, it's an area that has
come under much criticism in terms of usability and delays. You say that the
snail-mail system is unecessary and that authentication should be strictly
online, like some banking systems. You challenge the technical experts to
find a way to implement online authentication. Believe me, we tried, we
tried. It's just not that simple.

The central issue is this: How do you verify that an online user registering
a call sign in LoTW does (or did) in fact legally hold that call sign?

First, is it really necessary to verify this? Can't we just trust people to
honestly register only call signs for which they are or were licensed?
Unfortunately, we can't. If a user can register any call sign without proof
of ownership, then the DXCC program can be gamed, undermined and generally
destroyed. True, it will be possible to detect certain violations. For
example, HQ could easily catch someone registering a bogus BS7 call sign.
Very rare  call signs require special documentation for acceptance into DXCC
(an inconvenient and snail-mail process that has generated many complaints
over the years), so it's relatively easy to catch flagrant cheaters. But
semi-rare and not-rare call signs aren't scrutinized to the same degree. If
I didn't have to prove ownership of a call sign, it would be simple for me
to register fake call signs from 100 countries and anonymously award bogus
DXCC certificates for myself all my similarly underhanded friends. Simply
the information that even one person has obtained a DXCC certificate under
false pretenses would seriously undermine the program. And with a purely
online system, we probably wouldn't be able identify who did it. We might
not even be able to detect that it happened at all or which records are bad.
Further, if I can register any call sign, I can misappropriate call signs
that belong to other people, locking them out of the system. This is a
correctable problem -- when the real owner complains, the bogus certificate
can be revoked and the bad records identified and deleted (another nice
advantage of digital signatures.) But this attack will cause a disruption
and annoyance for the real owner of the call sign. It's called a
denial-of-service attack, and many similar DOS attacks are possible.
Although most are correctable, the end result will be frustration and
disgust among the affected users.

If you don't agree that we have to somehow validate ownership of the call
sign, then we're never going to agree about LoTW. Some say it's just a hobby
and that we shouldn't get all bent out of shape about it. I contend that
millions are spent by thousands in pursuit of DXCC, and that it's worth
protecting. Heck, even the infamous E-QSL recognized that they would never
qualify for DXCC without checking license ownership and provided that as an
option (though not properly implemented to avoid fraud.)

OK, so if you agree we have to verify that an online user owns the call
sign, just how can we do that? Online users are completely anonymous. It's
easy to spoof IP addresses and e-mail addresses, so that won't help. How
about something only the user knows that we can verify? That's the approach
used by some online banking systems. They ask for your social security
number, address, and other personal information that supposedly only you
know. Two problems with that. First, the provider has to be able to verify
the information. Banks are in a much better position to do that than ARRL,
especially with social security numbers (can you imagine the hue and cry if
ARRL asked for your SS#???) Second, personal information about anyone is
relatively easy to obtain. Identity theft has befome rampant in recent
years. I had my American Express card number and address stolen a couple of
years ago and it was a nightmare that took me 18 months to clean up.

How can banks rely on such flimsy security? Heck, none of them uses PKI --
your account is protected only by a password that you supply (sometimes
strong passwords aren't even enforced.) Well, some banks do go the extra
mile. I had to fill out and mail paperwork to open certain accounts at a
brokerage. Some banks still send you a password via postcard (sound
familiar?) Other banks call to verify you are trying to open an account.
Others introduce a delay while your personal information is verified. Most
credit card companies will not give you online access unless you know the
social security number and card number (note: the card is sent via
snail-mail to your address.)

But there are some banks that have decided to make it super easy. They
figure that a certain percentage of fraud will occur, and that they'll lose
money when you claim it has happened. There's a reserve for fraud in their
balance sheet, and it's simply figured in as a cost of doing business.
However, don't assume that they'll just bend over and believe you when you
claim someone has busted into your account and stolen all your money. It can
be very difficult to prove that it wasn't you. Many banks will make you jump
through incredible hoops, to the point where you may give up fighting (they
hope you will.) Even if they believe you, most will not even investigate the
fraud. It's cheaper to write it off. So, they never close the loopholes.
Believe me, I went through this with American Express and was shocked by
what I saw and what I had to do. In the end, I had to get my local police to
fill out a crime report before companies would stop dunning me -- because
American Express wouldn't take the time to verify that my card had been
stolen.

Unfortunately, ARRL can't just write off fraud in the DXCC system. Once the
system is undermined, people will lose confidence and the whole thing will
come crashing down.

Back to authentication: The LoTW snail-mail system for US call signs is an
elegant way to verify that someone is the owner of a particular call sign.
It's not inherently hard to use: the heavy work is done by LoTW behind the
scenes. You give it the call sign, it looks up the call sign in the FCC
database, it gets your address, it generates a password, it mails you the
password on a postcard. All you have to do is enter the password.
Unfortunately, confusing rules and terminology have made this process opaque
to many users (e.g., "This is not the same password as your LoTW logon
password!)

Yes, the system introduces a few days or a week of delay. Nobody likes that,
and I don't, but I still think it's a one-time inconvenience that's well
worth the lifetime of convenience and cost-saving LoTW can potentially
offer. That said, there's plenty of room for improving how it's presented
and explained to users.

As I mentioned, the authentication process for DX users is not as elegant.
Reliable online license databases simply don't exist for virtually any DX
country. The only alternative we could come up with was a copy of the
license. I dislike this part of the system, and realize that it's been a
major barrier to acceptance of LoTW by DX stations, but I know of no other
way to reliably verify the holder of a DX call sign. And it's the DX call
signs that make the DXCC system worth a lot to its users. They're the call
signs that need to be verified the most.

If anyone can come up with a better way to reliably prove ownership of a
call sign, I'm all ears!

It's not a great situation. Same goes for the QTH and licensing issues
mentioned above. They're part of ham radio and part of DXing. Some of the
complexity of LoTW is inherent in the job it's trying to do. That said, I
think it's incumbant on ARRL to keep refining the software, procedures and
documentation to make it as friendly and easy as possible. I think there's
lots of room for improvement, but still feel the underlying authentication
and PKI requirements are essential.

I totally agree with your suggestion to "Make solutions that are available
today easier to learn about and implement", and to not force everyone to
reinvent the wheel.


1/5/2007
Just catching up on reading newspapers. Tuesday's Wall Street Journal, page
D2, has an article entitled, "How Safe Is Your Online Bank". Here's the
introduction:

"Remember when online banking was supposed to be the stress-free alternative
to standing in long lines to make a transaction? All it took was a user name
and a password to get into your account. No more. New federal
online-security guidelines designed to foil Internet thieves from draining
accounts require financial institutions to adopt new security procedures. In
addition to passwords, such techniques include requiring consumers to
register each personal computer they use for home banking and a
face-identification quiz."

The article goes on to discuss how the new security systems make it less
convenient to access your account. So much for easy online banking.

Note that the new procedures are mainly designed to keep people from
stealing your money once you set up access to your online account. They
don't do anything to prevent people who have already stolen your identity
information from setting up access to your account without your knowledge.
Some banks are trying to get around this by asking for more and more
personal information, like social security numbers, tax id numbers, etc. But
those can be stolen, too. In the end, the banks and feds will realize that
you need to have stronger proof of identity than can be provided solely over
the Internet, which masks the user. I suspect they'll eventually go back to
systems where they mail you an initial access password, or maybe even
require you to show up at the bank to get it. 

There's no free lunch. Easy access means low security. Like the speed of
light, it's the law.

73, Dick WC1M