Kerberos transport DNS record design

[Petr Spacek]

On 1.6.2016 17:33, Greg Hudson wrote:
> On 06/01/2016 10:49 AM, Matt Rogers wrote:
>> The wiki page should be up to speed now. I added some additional notes
>> about priority and fallback behavior that were discussed in IRC. A
>> quick review would be appreciated.
>>
>> https://k5wiki.kerberos.org/wiki/Projects/KDC_Discovery
> 
> * I'm not sure the term "discovery" is correct, since we know a realm
> name and are just trying to figure out how to contact it.  (Compare to
> "discover the printers available on my local network.")
> 
> * The TXT payload is not formatted using a URI.  We believe we could
> transition to URI by creating a new URI scheme and stuffing everything
> after the weight into the residual part of the URI.  But there is no URI
> scheme in the payload, and we don't plan to register this URI scheme
> until we need it.

Right now TXT usage is not sufficiently specified:

1. Should multiple KDCs be specified as multiple RRs with one character string
OR as multiple character strings in one RR? (RFC 1035 section 3.3.14)
- Consequently:
What happens if an attacker sends the other possible encoding?

2. But wait, what is the TXT's encoding? TXT is just a binary blob.
- Consequently:
What happens if there is binary 0 in the middle of TXT data? ...
Is limitation to 255 octets in TXT a problem?

3. What about IDNA? Unicode? Or just space, slash or colon in the URL? How it
gets encoded?

I'm sure I missed something else which is under-specified. Again, proper URI
record would solve all this.


4. Is it a good idea to require IP addresses in the TXT? It means that IP
address change needs to be done on one more place (it is not sufficient to
change A/AAAA record anymore) which adds maintenance burden.


> * The 'M' (master) flag is only relevant to KDC lookups, but other
> future flags might not be.  So saying that the flags field is ignored
> for kadmin and kpasswd lookups is problematic.
> 
> * I wouldn't bother describing the "tls" transport.  It was just an
> example of a possible future transport.
> 
> * There is no currently defined or implemented http transport for
> MS-KKDCP (there is only https).
> 
> * I would just specify that priority and weight are as defined in RFC
> 2782, and that weight may or may not be implemented while priority must be.
> 
> Also, we should explicitly decide whether flag letters are
> case-sensitive.  In a side conversation on IRC, Simo argued that DNS
> data is traditionally case-insensitive.  I don't have an opinion.

Is 26 flags enough or do we want 26*2? :-)


Getting back to original discussion, I still believe that TXT usage is a bad
idea for several reasons.


a) First thing is due diligence:
Did someone test adding URI records before jumping on TXT?
Was an support ticket opened if it did not work?
What was the answer?
Where are the data? :-)

I've opened couple tickets for my DNS domains I personally own. First answer I
got is "let us know what records we can add for you", waiting for an answer
from others.

Of course, it could be much quicker (and with higher negotiating power) if the
tickets were opened using company account but somebody with appropriate
credentials would have to do it ... and this requires interest in getting hard
data.



b) IMHO we should not jump to TXT without an attempt to get URIs added.
Jumping right to TXT without hard data is a wrong idea for reasons explained in
http://mailman.mit.edu/pipermail/krbdev/2016-June/012604.html
http://mailman.mit.edu/pipermail/krbdev/2016-June/012608.html

It would be naive to think that the record will be parsed only by Kerberos
libraries and nothing else. Parsing will not happen in one place anyway
because DNS admins (humans)/IPA framework/user interface code will hardly call
krb5 library to parse it.

For this reason it is very illusory to think that not using standard
pieces will not save time.

It just makes it harder for other components of DNS system to tailor the
response as needed because it is impossible to use standard DNS
parsers.



c) Even more importantly, it makes it harder for users to use the thing
because they will have to learn a new syntax and deal with multi-part TXT
records, which could be a UI problem too when we are at it.
E.g. I did not see ability to add multi-part TXT records in Azure:
https://azure.microsoft.com/en-us/documentation/articles/dns-operations-recordsets/



d) Speaking of middle-boxes and URI filtering, Netalyzr study from 2011 [1]
shows this:
- 98.3% of clients is able to resolve TXT records
- 97.2% of clients is able to resolve made-up type 169 (not allocated
at all)

URI should be somewhere in between because it is standardized. Also,
5 years passed and a lot of networks could have been patched.

Considering all this I do not think that URI blocking is relevant
problem.

[1] https://www.icsi.berkeley.edu/icsi/publication_details?n=3112

-- 
Petr Spacek  @  Red Hat