Skip to content
December 8, 2019 / Jim Fenton

Japan/Singapore Day 3: More Kyoto

November 10, 2019

After another breakfast at the Starbucks next to our hotel, we took the subway and a light-rail line to Arishiyama, on the west side of Kyoto, on the recommendation of Emi, a friend of Kenna’s. Emi’s dad was from Kyoto, and Emi provided us with beautiful hand-drawn maps he had made that were immensely helpful.

Bamboo Forest

It was a nice change of pace to get out of the center of the city. It was, however, a sunny Sunday afternoon during the fall color season, which attracts crowds. Once there, we took a path through a bamboo forest, which was impressive in size but made us wonder how they kept the bamboo from spreading everywhere. We eventually turned off into a private garden that charged admission; it gave a chance to walk through a well-kept Japanese garden and enjoy a fine hilltop vantage point. It was well worth the price of admission for this. We then followed a path into a nearby park and along the Katsura River.

Crossing the river by a nearby bridge, we found an udon restaurant for lunch. Mine (udon with tempura) was quite good, but the beef with Kenna’s udon was less enjoyable.

Kiyomizu Temple

After lunch we took the rail and subway across town to the north end of Muruyama Park and walked through it and then through a popular shopping district with many traditional stores. Many young people in couples and groups were dressed in traditional costume for a day out. We arrived at to Kiyomizu Temple, one of the more notable Buddhist temples in the Kyoto area. We admired the architecture and artwork, but wish we understood more about the various rituals going on there, such as the ringing of a gong and the various prayer sites.

Leaving the temple, we walked through a huge cemetery leading back into central Kyoto. At this point it seemed like we had done quite a bit of walking. We made our way back to the subway, and north and east to a district known as the geisha (Gion) district. We walked around a bit, finding a place called Gion Corner where there are twice-daily performances, but decided not to attend one. The restaurants in the immediate vicinity were rather expensive, so we took a break from Japanese food and stopped for dinner at an Irish pub we had walked by. Kenna sampled and enjoyed the sake, learning about how it is traditionally poured and consumed.

We returned to the hotel through a very active shopping district. It’s Sunday evening, but apparently that doesn’t stop the shopping culture in Kyoto.

Total walking today: 10.5 miles, 27 floors climbed

This article is part of a series about our recent travels to Japan and Singapore. To see the introductory article in the series, click here.

December 7, 2019 / Jim Fenton

Japan/Singapore Day 2: Kyoto

November 9, 2019

Nijo Castle entrance

We awoke in Kyoto to a beautiful sunny day. Despite jet lag, we both got a reasonable night’s sleep and got up at a normal time this morning. We had breakfast at a Starbucks next to the hotel, since we prefer Western-style breakfasts and weren’t sure what else to do. We found that the meal options at Japanese Starbucks are somewhat more limited, but still quite acceptable.

We decided to do a hop-on/hop-off bus tour to get an overview of the city and it would take us to a few places we wanted to see. We took a short walk through a pleasant neighborhood to the bus stop and noticed that we were in a banking district, and since we were using credit cards and a little leftover yen from a previous trip, we decided to get some cash from the ATM. That’s where we ran into the major challenge of the day.

There were several banks near the bus stop, so we picked one, found an ATM with an English button (reassuring), and tried to get some cash. Just when it would have dispensed the cash it returned my card with a “receipt” saying it couldn’t read the card. Same thing happened with Kenna’s ATM card, and we couldn’t use our credit cards because they don’t have PINs. The next ATM we tried had a sign on the door saying (in English) “Japan domestic ATM cards only”. That saved some time. We tried one or two more to no avail, so returned to the bus stop and bought bus tickets with a credit card.

Our first stop was at Nijo Castle, one of the premier tourist attractions in Kyoto. On the recommendation of our guidebook, we opted to get the audio guides. We learned a great deal about the structure: a classic castle in the sense of being surrounded by a water-filled moat, but in Japanese style. The shogun’s home was impressive, with many rooms for receiving visitors of various ranks. But I needed to remind myself that these buildings are really old — although they have been rebuilt at various times in history. I noticed that the rooms were connected by hallways, a fairly recent architrave development, at least in Western buildings.

Via the bus, we stopped next in the grounds of the old Imperial Palace prior to the moving of the Japanese capital to Tokyo in the 1868. By this time, we were rather hungry, so we stopped at a restaurant in the park surrounding the Palace. When we went to order, we noticed a “Cash Only” sign, and immediately our ATM problems became more serious. We found another ATM outside the park, and again no luck. Although hungry, we toured the Imperial Palace grounds, which were worth seeing, but Nijo Castle was a hard act to follow. The hunger didn’t help either. We returned to the bus stop and found a burger joint near there that accepts credit cards, so at least we got fed.

Somewhere along the way to the next stop, I did an internet search for “Japan ATM problems” or something like that. An article on japan-guide.com told me that others have had the same problem, but that the ATMs at the 7-Eleven stores generally work for foreign ATM cards. I don’t generally use ATMs in convenience stores, but in Japan apparently 7-Eleven stores are associated with “7-Bank” and very reliable with reasonable fees. 7-Eleven as a bank makes me feel like I’m in an alternate universe.

We stopped in the vicinity of a craft museum we were interested in visiting and walked to a nearby 7-Eleven, and voila, we were able to get cash from their ATM. We celebrated (and broke the large bills from the ATM) with a couple of ice cream cones.

The craft museum is unfortunately closed for renovations for several months, but a Shinto shrine, the Heian Shrine, was right nearby and worth a visit even if we don’t understand much about the religious significance. There was also a nearby outdoor market that had a variety of interesting and unfamiliar goods.

We got back on the bus and rode to Kyoto Station. Just outside, we ran across a series of elaborate (and very impressive) dance performances by groups of young people, which we watched for a while.

We went up Kyoto Tower and got a view of the city from there, although by this time it was getting dark. We then went looking for dinner, which was an unexpected challenge; it was Saturday night and many restaurants were full. We ended up going to the Food Court below Kyoto Tower and got a quite reasonable dinner there — we need to remember these food courts as good options in the future. Although we couldn’t communicate well, we connected with a friendly couple at the next table, who shared a bit of candy with us as they departed.

Total walking today: 9.7 miles, 12 floors climbed

This article is part of a series about our recent travels to Japan and Singapore. To see the introductory article in the series, click here.

December 5, 2019 / Jim Fenton

Japan/Singapore Day 0-1: To Japan

November 7-8, 2019

Flight map, SFO/KIX

It has been quite a while since we’ve taken a trip that has lent itself to a travel journal, but we’re leaving on one this morning. I have been planning to travel to Singapore for the 106th Internet Engineering Task Force meeting, and wanted to bring Kenna along this time since we’re now empty-nesters.

Kenna wasn’t enthusiastic about the 17-hour flight from San Francisco to Singapore, so we’re taking the opportunity to spend a week in Japan on the way there. Our plan is to fly to Osaka, take a couple of days in nearby Kyoto, followed by a couple of days in Tokyo, before continuing from there to Singapore.

Your characters for this adventure are myself, Jim, and my wife Kenna. There will also be mention of our daughter Celeste, who is a student at the University of Colorado and unfortunately not accompanying us. As with past travel journals, this is mostly written while on the trip, and edited and posted on the blog day-by-day as we return, offset by a few weeks.

I have been to all of these places on business, but haven’t had much time for sightseeing. This is Kenna’s first trip to Asia. It will be fun to see it from the perspectives of both someone who has been there before and someone for whom all of this is new.

I went out to get the newspaper this morning, and it was quite foggy. This concerned me a bit, because it could spell a considerable delay in our flight. Fortunately the United app tells what incoming flight the plane arrives on, and I was reassured to learn that flight (from Denver) was in the air, and not subjected to a ground stop.

The incoming flight was delayed a few minutes, and accordingly our flight was delayed by just a few minutes to allow for servicing. Once in flight, we crossed the Date Line and arrived in the afternoon of the next day.

Hello Kitty themed train (Osaka to Kyoto)

Immigration and customs were fast and efficient on arrival, and we bought train tickets to Kyoto at the Tourist Information. Unfortunately it was getting dark so we didn’t see much of the countryside. Upon arriving at Kyoto Station, we navigated our way to the subway and on to our hotel.

Our hotel, the Gracery Hotel Kyoto Sanjo in the central part of Kyoto, is connected to a few streets that form a pedestrian-only shopping district. Once we got our room (a very comfortable, but not overly large one), we wandered around looking for dinner. We were about to “give up” and have pizza or something when we found a small sushi restaurant. The sushi was fortunately described in English on the signs and we had a very enjoyable meal (good, but not fabulous sushi) for a little less than it would have cost at home. Then we returned to our room about 9 pm and crashed for the night.

December 1, 2019 / Jim Fenton

Requiring TLS transmission of email

RFC 8689 cover page image

It’s considered a “best practice” to support Transport Level Security (TLS), which encrypts traffic over the internet (including this web page), for submission and relay of email messages. Yet many email messages are sent without TLS protection, unbeknownst to their senders, so it’s not something that can be depended upon. Email systems generally prioritize delivery of email over security (something I refer to as the “nor rain nor sleet” principle) so if TLS can’t be negotiated for some reason, the message is sent in the clear.

This past week, the Internet Engineering Task Force (IETF) published “SMTP Require TLS Option” as a Standards Track specification, RFC 8689, to address this.

A few years ago, I became aware of research [1] providing strong evidence that certain countries, notably Tunisia, actively interfere in the negotiation of TLS on email connections, presumably so that they can intercept and read the traffic. It occurred to me that for sensitive traffic it might be preferable to allow the message to be sent only if TLS can be successfully negotiated, and to return an error if this can’t be done. So in early 2016 I wrote the first draft of the REQUIRETLS specification, and submitted it as an IETF Internet Draft.

The way it works is this: when email is sent using the SMTP protocol over the internet, it can be tagged with a “REQUIRETLS” option. Messages tagged with this option can only be sent to mail servers over TLS connections that verify the SMTP server’s identity, and where the mail server receiving the message also advertises that they also support and honor the REQUIRETLS option for onward relay of the message. If none of the email servers to which the message could be relayed meet those requirements, a “bounce” message is returned to the sender.

This raised a number of questions, such as:

  • Why not use end-to-end encryption, such as S/MIME or PGP? These encrypt only the body of the message, so all the header information (To and From addresses, Subject, etc.) are still exposed. This is very valuable information for adversaries doing traffic analysis. You often want both transport-level encryption (TLS) and end-to-end content encryption.
  • What’s to prevent a mail server from advertising REQUIRETLS and then not honoring it? Nothing, but we’re talking about mail servers that the recipient trusts enough to allow them to be used to accept email on their behalf, so one expects they’re trustworthy enough also to honor a commitment to do REQUIRETLS properly.

As it happened, a complementary specification, MTA-STS, was in the standardization process and intending to solve a similar problem. The goal of MTA-STS is to allow a domain that receives email to advertise the fact that they support TLS, so that if it cannot be negotiated the discrepancy can be detected. One of the challenges with MTA-STS is how to advertise that fact in a way that cannot be altered by an intermediate adversary. This is addressed in the MTA-STS specification, RFC 8461. This is also the goal of DANE, an existing protocol (RFC 7672) that allows domains with DNS Security (DNSSEC) configured to advertise their use of TLS.

But another challenge is how the sender of a sensitive message can know that MTA-STS will be checked as the message is relayed. They might know that the recipient domain publishes an MTA-STS policy, but it’s harder to know whether or not the intermediate hops will honor that policy. It’s in this way that MTA-STS and REQUIRETLS are complementary.

On the way to standardization, one significant additional feature was added. There are times when the sender of a message wants explicitly to ignore MTA-STS and DANE policies, for example when they want to report a misconfiguration in these mechanisms. A new header field, Require-TLS (with mandatory value NO) was added to allow that to be asserted. Servers that support REQUIRETLS and encounter this header field are expected to relay the message without regard to those policy mechanisms. Of course, since the goal is to enhance delivery of the message, it isn’t appropriate to relay the message only if the recipient SMTP server supports it, so support of this header field can’t be depended upon by the sender.

At this writing, no known commercial products yet support REQUIRETLS, although I have been in touch with the MDaemon people who are actively implementing it for their products. There was also an early implementation for the Exim open-source mail server that needs to be brought up to date with the latest specification.

REQUIRETLS is a bit of email infrastructure; nothing in the specification addresses how users will turn it on, either on a per-message or per-domain basis, or for all messages they send. I’m hoping to see some creative solutions for that: perhaps a button on the user interface or some rule causing mail to particular domains or addresses to be tagged REQUIRETLS.

I’m hoping that now that it’s a published standards-track specification, REQUIRETLS becomes a standard part of the email toolkit to enhance senders’ control over the security of messages they send.


[1] Durumeric, Zakir, J. Alex Halderman, David Adrian, Ariana Mirian, James Kasten, Elie Bursztein, Nicolas Lidzborski, Kurt Thomas, Vijay Eranti, and Michael Bailey. 2015. “Neither Snow Nor Rain Nor MITM…: An Empirical Analysis of Email Delivery Security.” In , 27–39. ACM Press. https://doi.org/10.1145/2815675.2815695.

January 16, 2019 / Jim Fenton

Another NIST SP 800-63 mirror

Many people seem to be having trouble accessing NIST publications with the current partial* government shutdown, so at the risk of redundancy, here are copies of the documents in the NIST Special Publication 800-63 Digital Identity Guidelines suite:

*partial, in this case, seems to refer to the interesting parts of the government.

Please do not link to these, as they are not intended to be an archival source and will be taken down once the government is again fully functional.

November 3, 2018 / Jim Fenton

In memory of my grandmother and the Great Influenza

Anna Crandell Robson and children

Today is the 100th anniversary of the death of my grandmother, Anna Crandell Robson, at the age of 33. She died of influenza only five days after her husband, Findlay Robson, and seven days after Findlay’s brother Neil. The death of Anna (usually called Annie) orphaned my uncle Fremont (age 5), aunt Pat (2), and mother Mary (15 months).

Anna grew up in Lindsay, Ontario, the eldest of five children of Fremont Crandell and Irene Fee. She was the granddaughter of Captain George Crandell, who was well-known in the area as the operator of a number of steamboats that operated in the Kawartha Lakes area of Ontario at the time. Prior to their marriage in 1910, Annie had worked at Flavelle Flour Mills, at the site of the mill ruins in Lindsay, Ontario. Since Findlay was in the grocery business, it is likely that they met through that connection.

They moved to British Columbia about 1913, where all three of the children were born. Her younger sister, Agusta (“Gussie”) lived in Calgary, Alberta, the wife of Charles Elliott, a Canadian Pacific Railway employee. Gussie came to Cranbrook to take care of the children at some point (the timing is uncertain, but perhaps before Annie passed). After Annie died, she reportedly had planned to adopt the children; she and Charles had none. However, Gussie also contracted the flu, and died on November 14 at the age of 26. Another relative, perhaps Annie’s mother, came to Cranbrook to retrieve the children and bring them back to Toronto, where they were raised by the families of two of Findlay’s brothers.

The family was thus devastated by the deaths from influenza of four young adults between ages 26 and 37.

October 29, 2018 / Jim Fenton

In memory of my grandfather and the Great Influenza

Today is the 100th anniversary of the death of my grandfather, Findlay Robson, at the age of 37. Findlay (sometimes spelled Finlay) and his wife Anna (Crandell) Robson lived in Cranbrook, British Columbia, where he was the manager of Cranbrook Jobbers, a wholesale grocer. They had three children, Fremont (age 5), Pat (2), and my mother, Mary (15 months).

Findlay grew up in Fenelon Falls, Ontario, about 100 miles northeast of Toronto. His father, William Lithgow Robson, ran the local grocery and Findlay got his start in the grocery business there. Findlay and Anna were married in 1910, and in about 1913 they moved west to British Columbia.

Findlay died of pneumonia that was caused by the great influenza pandemic that year. Newspaper reports said that Cranbrook was hit hard by that flu outbreak; the papers were operating with a reduced staff because of the number of people down with the flu.

Findlay Robson obituary
Findlay Robson obituary, The Cranbrook Herald, October 31, 1918

Only two days before, Findlay’s brother Neil died in Toronto of influenza. According to a newspaper report, his brother’s death “took away the fighting chance he had for his life.”

100 years later, we have the benefit of a much better understanding of what causes influenza and the availability of flu vaccines that, even if not 100% effective, can make the difference between a severe case of the flu and a mild one. I make a point of getting a flu shot every year, both to keep myself from being down with the flu, but also to honor my grandparents’ memory. I recommend the same to everyone.

Spoiler alert: Anna died of the flu a few days later. I will post another article about her on that anniversary.

June 11, 2018 / Jim Fenton

The need for provenance with BYO authenticators

The alternative to BYO authenticators

There is a strong desire to allow users of two-factor authentication to “bring your own” (BYO) physical authenticator (often referred to as a “token”). This relieves the user from keeping (and keeping track of) separate physical authenticators for each service, and spreads the cost of authenticators among multiple services. It also simplifies the process of enrolling a new user in an account when a physical authenticator does not need to be conveyed (e.g., mail, in person) to that user. Bringing your own authenticator, however, adds a new element of uncertainty.

The impact of an account breach is not limited to the user: the service, and often other users, are often also impacted. The service, at a minimum, has to bear the cost of incident response, even if that only involves aid to the user. Account breaches may affect other users on the service or impact the service itself (consider industrial control systems and critical infrastructure here). It isn’t just the user that has a stake in the security of authentication.

When authenticators, particularly hardware-based physical authenticators, are issued by the service itself, the service knows all about their strength. For example, if the user is issued a one-time password (OTP) device, the service knows that the authenticator secret is embedded in hardware, what the characteristics of that hardware are, and can assess the strength of authentication accordingly.

If the user brings their own authenticator, how can the service make that determination? For many authenticator types, particularly where the strength is determined by the authenticator’s hardware characteristics, more information is needed.  For example, it is generally not possible to distinguish an authentication made using a cryptographic device (e.g., smart card) from one made using a software-based cryptographic certificate. The protocols for those two authenticators can be identical.

Fortunately, some authenticators are beginning to provide assertions of their provenance along with the authentication transaction. Most notably, FIDO authenticators supply signed assertions about the type of authenticator used, assuming of course that the authenticator maintains its integrity. In practice, this information is most valuable for high assurance authenticators, and these are the ones that protect their integrity the best.

For other BYO authenticators, it’s probably safest to assume the worst: that a relatively weak authenticator is being used. For client certificate-based authentication, assume that the certificate is held in software and is not protected by a passphrase. For one-time passwords, assume that a software implementation is being used in the absence of reliable information to the contrary.

It took me a while to appreciate the value of provenance assertions; at first, I had viewed them as a DRM-like feature to allow only licensed authenticators to be used. But they have real value in establishing the strength of the authentication transaction.


Image “RSA Tokens” by Flickr user Edwin Sarmiento used under Creative Commons BY-SA 2.0 license.

 

March 8, 2018 / Jim Fenton

Passwords: what minimum length?

Recently there has been a fair amount of discussion about what the minimum acceptable length of passwords should be. NIST SP 800-63B sets a minimum of 8 characters. Some people think the minimum should be considerably more than that, perhaps 16 characters. The following is some rationale for why 8 is a reasonable minimum.

A 2014 research paper[1] was a significant factor in informing this guideline. As discussed in Section 3.2, guessing attacks on passwords can be categorized into online and offline attacks. Online attacks are limited by available bandwidth, response time of the verifier, and hopefully by active throttling of the number of guesses allowed (as specified in SP 800-63B section 5.2.2). Offline attacks, where the attacker has been able to obtain a password database (hopefully salted and iteratively hashed), can make many more guesses, with guessing rates in excess of 1 billion guesses per second depending on the attacker’s hardware capabilities. There isn’t anything in between: either the attacker has a password database to use and mounts an offline attack, or they don’t and mount an online attack.

As a result, there is a significant range in password lengths, shown in Figure 2 of the paper (reproduced above), where passwords are long enough to be resistant to online guessing attacks, but are not long enough to be resistant to offline attacks. Within this range, increasing the minimum password length adds to the burden on users, but does not significantly increase security. While SP 800-63B does not attempt to estimate entropy (or the estimated number of guesses required) for a given password length, the current guideline of 8 characters exceeds the length needed to protect against online attacks, particularly since the paper doesn’t assume intentional rate limiting by the verifier.  However, a considerably longer minimum password length, probably at least 16 characters, would be needed to protect against offline attacks, and that would increase with computing speed.

Users do predictable things when subjected to onerous authentication requirements, such as the common behavior to append an exclamation point to their password when required to use a special character. Rather than impose an onerous length requirement (which might cause them, for example, to just use their shorter password twice), the decision was made to set the minimum password length to be resistant to online but not offline attacks. Instead, the burden was placed on the verifier: SP 800-63 section 5.1.1.2 calls for verifiers to store memorized secrets in a form that is resistant to offline attacks, including use of a salted key derivation function and also suggests an additional keyed hash with a secret key that is stored separately.

SP 800-63-3, which contains guidelines on selection of the Authenticator Assurance Level (AAL), calls for two-factor authentication in a number of situations where it has not typically been used. In particular, Executive Order 13681 requires federal agencies to use two-factor authentication whenever a user’s personal data is being released. This is largely in recognition of the limited security that passwords can provide due to not only the guessing attacks discussed above but also other threats such as key loggers. Given the modest security that can be achieved, increasing the minimum password length would be an inconvenient and incomplete solution to authentication security.

Note: While I am a co-author of NIST SP 800-63-3 and SP 800-63B, I am an independent consultant and the above discussion is my opinion only and does not necessarily represent the position of the National Institute of Standards and Technology.

Illustration above is from reference [1].


[1] Florêncio, Dinei, Cormac Herley, and Paul C. van Oorschot. “An Administrator’s Guide to Internet Password Research.” Usenix LISA, November 2014. http://research.microsoft.com/apps/pubs/default.aspx?id=227130.

December 5, 2017 / Jim Fenton

Protecting passwords against cracking with rehash

One of the problems with the way that passwords are usually verified is that all of the information needed to do the verification is in one place. The password table contains everything that is needed (salt + hash) to verify a password. So if that table is compromised, and that seems to happen a lot, most users are vulnerable because hash cracking technology is, sooner or later, going to crack the vast majority of those passwords by dictionary attack and brute force. Efforts to defeat this have mostly centered around making it harder for the crackers by using iterated memory- and time-intensive algorithms to do the hashing.

Another (an additional) approach is to also hash using a secret value that is stored securely. This is recommended in NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management, in the last paragraph of Section 5.1.1.2. This keyed (or “secret salt”) hashing step can be isolated from everything else and treated as a black box that accepts password hashes and outputs a rehashed value. The premise is that it’s easier to protect a secret in a black box than it is to protect a database of hashes and salt values that is used directly by the verifying application.

With the additional use of a secret-keyed hash with a sufficiently complex key, it is impractical to dictionary attack a database of hashed secrets unless the key is known.

Hashing passwords with individual random salt values is still essential. Without that step, it might be possible for an attacker to create fake accounts with known passwords, then compromise the password file and see if any of those hash values appear elsewhere in the database. I am also a believer in defense-in-depth, so I also recommend continued use of iterated hashing so that security is no weaker than the current situation if the key is somehow obtained by an attacker.

Some people have commented that this requires the use of a hardware security module (HSM). While HSMs are the ideal black boxes and provide excellent protection for the key, they can be expensive to obtain and deploy, especially in cloud environments. As an alternative, I have written a sample application, rehash, that implements a very simple web API to accept a hashed password, hash it with a private key, and return the result. The rehash application should run on a machine separate from that doing the password verification, and separate from anything else that could compromise the secret key. The rehashed password would be stored in the password verification table and, when a password is entered, the iterated hashed password is rehashed and that value checked against the table.

I have huge respect for the people in the password cracking community that I have met. They have done groundbreaking work in understanding user behavior and using that to optimize the search for passwords in their cracking process. But it is time that we implement something that makes this sort of cracking entirely impractical, rather than just ratcheting up the work factor for them.

I welcome any comments on the rehash application, either through comments here or (perhaps better) by opening an issue on GitHub.