Bug ID: JDK-8210822 Support dns_canonicalize

Type: CSR
Component: security-libs
Sub-Component: org.ietf.jgss:krb5

Priority: P3
Status: Closed
Resolution: Approved
Fix Versions: 12

Submitted: 2018-09-17
Updated: 2018-10-02
Resolved: 2018-10-02

Summary
-------

Support the krb5.conf `dns_canonicalize_hostname` as defined in https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html.

Problem
-------

When constructing a sevice principal name (in for form of `service_type/host_name@REALM`), we always try to get the canonicalized name of the host name. This is not recommended by [RFC 4120](https://tools.ietf.org/html/rfc4120#section-1.3) and could have a serious impact on performance.

Solution
--------

Support the `dns_canonicalize_hostname` setting.

Specification
-------------

Currently, Java performs a "smart" canonicalization, i.e. it always calls `host.getCanonicalHostName()` but only accepts the result if the canonicalized name is a longer version of the original name (For example, "service.example.com" is a longer version of "service").

We propose that if `dns_canonicalize_hostname` is set to "true", we continue using this "smart" canonicalization; if "false", no canonicalization is ever tried and the original name is always used. The default value is "true".

This will be documented in https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/jgss-api-mechanism.html. This is linked from the JDK 9 security guide at https://docs.oracle.com/javase/9/security/java-generic-security-services-java-gss-api1.htm.

Moving to Approved.
02-10-2018
Moving to Provisional.
01-10-2018
After some discussion in #corelibs-hallway, I am convinced that the current "smart" canonicalization is indeed what we want "true" to be. So I've removed the "always-canonicalization" choice and now it's a real boolean setting.
29-09-2018
I updated the specification and named the 3rd value "fqdn-only". So this setting is now boolean for MIT krb5 but has 3 states in JDK. When it's not set, the 2 implementation chooses different default values. I would describe this in a release note.
26-09-2018
OK, but in order to be interoperable with MIT krb5, the string value must include "true" and "false". I'll think about the 3rd one, it should mean "get a longer version" but I'll need a better word. "lengthen"? "expand"? "extend"?
26-09-2018
By default, when a boolean property is discussed, people reasonably assume the law of the excluded middle holds (https://en.wikipedia.org/wiki/Law_of_excluded_middle). That is, if the property is not true it is equivalent to being false and if a property is not false it is equivalent to being true. If there are three distinct values, I think it is confusing to try to describe this as a boolean value with "not set" meaning the third value. I suggest considering a non-boolean value to model a tri-state.
25-09-2018
My proposal is that there are 3 possible values for this setting: "true", "false", and not set. The default is "not set". Is that controversal?
25-09-2018
By my reading, the compatibility discussion and specification contain contradictory information. The compatibility discussion states "Without the setting, there is no behavior change." and the specification proposes: "Currently, Java performs a "smart" canonicalization, i.e. it always calls host.getCanonicalHostName() but only accepts the result if the canonicalized name is a longer version of the original name (For example, "service.example.com" is a longer version of "service"). We propose that if dns_canonicalize_hostname is set to "true", the canonicalized name is always used; if "false", no canonicalization is called and the original name is always used." Neither true nor false setting match the description of the current behavior. Marking the request as pended.
24-09-2018