Re: [apps-discuss] draft-hoffman-server-has-tls-04

[Keith Moore <[e-mail]>]

This is the first time I've looked at this document, so these are thoughts about the document as a whole, not just appendix A.  However, while reading through the document, I kept wondering how this applied to STARTTLS and similar schemes for doing in-band negotiation of TLS.

1. My first impression is that for protocols whose connection details are specified by URL, any kind of automatic negotiation of TLS (or not) might be the wrong thing to do.

http://example.com/foo.bar arguably means to use (a) raw HTTP and (b) port 80, regardless of whether example.com supports HTTP-over-TLS, or access on a different port.

https://example.com/foo.bar arguably means to use (a) HTTP over TLS, and (b) port 443, rather than some other port.

If the user typed in https, he has the right to expect TLS.  You definitely do not want the latter case to "fall back" to an insecure port without the user being aware of it, no matter what the DNS says.

I'll note that HTTP, at least, already has a fairly flexible redirect mechanism, so doesn't seem to benefit from HASTLS.  

So I guess I wonder if HASTLS should apply to protocols whose connection details are specified in a URL, especially if they're explicitly specified in a URL (as with literal port numbers).


2. Furthermore, if a port is explicitly specified in a URL, that definitely means to use that port.   But URL canonicalization routines usually delete an explicitly specified default port.  So even if a user (or a program) explicitly specifies http://example.com:80/foo.bar then that has a good chance of being rewritten internally to http://example.com/foo.bar even though port 80 was explicitly specified.    Naive implementation of HASTLS (or any other rewriting mechanism) would defeat the ability to use literal port numbers, for diagnostics, debugging, etc.  That isn't by itself a showstopper for HASTLS, but it does probably mean that some more detail is needed in specifying how HASTLS is used.


3.  Again regarding protocol connections specified by URL, I guess that if a server administrator wanted to publish some sort of mapping in DNS that said "any resources with names starting with http://example.com/foo can also be located at https://example.com/foo, and the latter is preferred", that might be useful.   Really, some of us have been wanting this since the mid 1990s at least, and NAPTR is fairly well suited to such mappings.   But the semantics of HASTLS aren't defined tightly enough to warrant that kind of interpretation.  


4. Especially in these days with widespread and increasing use of NAPTs, it seems dubious for a "please use TLS" solution to impose the constraint that the alternate protocol uses a separate port than the primary one.  


5. Something I've wanted for a long time is automatic configuration of various kinds of services.   Say you get an email account from your ISP, enterprise, whatever.  They give you an email address and a password.  Your mail client should be able to do a DNS lookup of your email address (say using NAPTR), and get back a list of records that say:

send outgoing mail to:
smtp.example.com using the mail submission protocol over port 587 using STARTTLS and plain authentication
access received mail using any of the following
imap4 over port 143 using starttls from imap.example.com; username = your email address (preference=1)
imap4 over tls over port 993 from imap.example.com; username = your email address (preference=2)
imap4 over port 143 from imap.example.com; username = your email address (preference=3)
pop3 over tls over port 110 using STLS from pop.example.com; username = your email address (preference=1)
pop3 over tls over port 995 from pop.example.com; username = your email address (preference=2)
pop3 over port 110 using APOP from pop.example.com; username = your email address (preference=3)
pop3 over port 110 from pop.example.com; username = your email address (preference=4)
a webmail client is also available at:
https://webmail.example.com (preference=1)

This would provide a very general way to encourage use of secure servers, as well as other advantages.  For instance, other services associated with the email address could also be specified:  instant messaging, public key, directory lookup (business card), home web page, VoIP, etc.

Again, I think that something like NAPTR is pretty close to being able to do this, though it needs to be profiled for this case.  The other pieces that are missing are suitable URL definitions for all of these protocols (SMTP, mail submission, POP, IMAP) and a way to embed "use STARTTLS" in those URLs.  (In some cases the URLs exist but might not have been designed with this purpose in mind.)

Keith