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

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 Mar 2011 15:09:23 -0800

Greetings again. Although the WG chairs said that it was fine to bring 
this document into the WG, I was hesitant to do so before dealing with 
all the issues that were raised in the earlier discussion. Try as I 
might, I wasn't able to resolve one significant issue, so I have kept 
this as an individual submission, listed below.

The issue is listed in Appendix A of the new draft. If people agree that 
one of the proposed solutions is fine, I can make that change and issue 
a new draft for the WG after the window opens in Prague. I suspect that 
there will be a lot of discussion of which proposal is best; if I'm 
wrong, I apologize for not having seen it early and turning this into a 
WG document before now.

--Paul Hoffman

==========

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : Specifying That a Server Supports TLS
	Author(s)       : P. Hoffman
	Filename        : draft-hoffman-server-has-tls-04.txt
	Pages           : 9
	Date            : 2011-03-12

A server that hosts applications that can be run with or without TLS
may want to communicate with clients whether the server is hosting an
application only using TLS or also hosting the application without
TLS.  Many clients have a policy to try to set up a TLS session but
fall back to insecure if the TLS session cannot be set up.  If the
server can securely communicate whether or not it can fall back to
insecure tells such a client whether or not they should even try to
set up an insecure session with the server.  This document describes
the use cases for this type of communication and a secure method for
communicating that information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-04.txt

---

From: Keith Moore <[email-masked]>
Date: Sat, 12 Mar 2011 19:16:53 -0500

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