Subject: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt

From: Paul Hoffman <[email-masked]>
Date: Sun, 16 Jan 2011 18:41:35 -0800

Greetings again. I would like this WG to consider adopting the following 
draft as a WG item. It is definitely apps-related, and there is no other 
appropriate WG in the Applications or Security areas for it. It has been 
discussed in the websec WG, but that WG is limited to HTTP only (and 
this document covers TLS for all application protocols).

FWIW, some of the topics in this draft are quite open for active 
discussion. The discussion in websec brought up some interesting issues, 
but they got discussed in the HTTP context only, and this WG would be a 
better place to discuss them for all server protocols.

--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-03.txt
	Pages           : 8
	Date            : 2011-01-16

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-03.txt

---

From: Barry Leiba <[email-masked]>
Date: Mon, 24 Jan 2011 21:35:22 -0500

Jiankang, Alexey, and I have discussed this, and we think the document
(see below) is appropriate for the appsawg to adopt, review, and
discuss.  I would like to hear, as soon as possible and in any case by
4 Feb, any objections to adoption of the document by appsawg.  I am
also asking participants here to please review the document and begin
discussion on this mailing list.

Barry, as appsawg chair

On Sun, Jan 16, 2011 at 9:41 PM, Paul Hoffman <[email-masked]> wrote:
> discussed in the websec WG, but that WG is limited to HTTP only (and this
> document covers TLS for all application protocols).
>
> FWIW, some of the topics in this draft are quite open for active discussion.
> The discussion in websec brought up some interesting issues, but they got
> discussed in the HTTP context only, and this WG would be a better place to
> discuss them for all server protocols.
>
> --Paul Hoffman
>
> _______________________________________________

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Jan 2011 16:39:00 +0100

Barry, Paul,

This is an important draft that has broad impact.  In particular, this
approach would trim the double IANA port assignment requests that do
occur and that we would like to see not occur.  I do have several
substantial comments about the draft:

1.  The draft states that DNSSEC MUST be used, and there is some logic
to this.  If you have an unprotected communication then it is possible
for both an upgrade DOS attack and downgrade MITM attack.  That having
been said, let's at least note that this is a substantial gating
function to implementation.

2.  I don't understand unde what circumstances CFB would be used.  The
reason that such fallback mechanisms exist is because the client doesn't
have knowledge of what server capabilities are.  In this case, the
server through DNS is expressing its capabilities to the client, so when
is CSO applicable?

3.  The presentation form of the new RR is not self-explanatory.  Might
I recommend something like (servicename-or-number/protocol TLS=port#
plain=port#).

4.  In the case of a hostname that offers many services and may be in
some way virtualized, the client may have to sift through quite a number
of 3-tuples to retrieve relevant information.  Another approach would be
to make use of a DKIM-like approach in the RR label, although one would
have to take care that a label not contain all numbers (I seem to recall
that's not allowed).

5.  Perhaps most important, this service should be generalized in a
different way.  What is being proposed here is a host connection policy
record.  TLS is not the only issue.  Another issue would be whether SCTP
is in use for a given, for instance.  I wonder if this draft should be
recast in a more extensible approach, so that a host doesn't need to
query for a bunch of records (TCP, DTLS, SCTP, etc.).

6.  Along these lines we should view this as an evolution of SRV.

Thanks,

Eliot

On 1/25/11 3:35 AM, Barry Leiba wrote:
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 26 Jan 2011 08:11:21 +0100

I have had a look at this, and have three questions:

1. Have I understood it correct if the client by using this RR can refuse to fall back to insecure connection for "communication using HTTP"? I.e. it seems the RR is specifying whether fallback is possible to not only per port, which works when you have "STARTTLS" or similar, but not when fallback is between ports?

2. If so, the "input" to the query should in that case be not only the hostname, but the protocol and hostname, right? So one could use a prefix-based mechanism like _http._tcp.example.com. IN HASTLS 0 443 0

3. I am always a bit nervous over RDATA that has variable length. Do you have an implementation of this so that you have tried to ensure "it works"?

Otherwise, as someone said, overall negotiation I think is interesting.

   Patrik

On 17 jan 2011, at 03.41, Paul Hoffman wrote:

> Greetings again. I would like this WG to consider adopting the following draft as a WG item. It is definitely apps-related, and there is no other appropriate WG in the Applications or Security areas for it. It has been discussed in the websec WG, but that WG is limited to HTTP only (and this document covers TLS for all application protocols).
> 
> FWIW, some of the topics in this draft are quite open for active discussion. The discussion in websec brought up some interesting issues, but they got discussed in the HTTP context only, and this WG would be a better place to discuss them for all server protocols.
> 
> --Paul Hoffman
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>

---

From: Benson Schliesser <[email-masked]>
Date: Wed, 26 Jan 2011 00:12:00 -0800

I support the general goal, and think this is a worthy WG item.

However, similar to what other folks have said:  I think using a single HASTLS resource record per host to carry a variable number of port/policy triples isn't the ideal approach.  Rather, a single port/policy triple should be associated with a protocol-specific record, i.e. a record name based on SRV.

If the SRV record format is leveraged, the HASTLS protocol needs to define what service name gets used as a record name - the non-TLS version (_http._tcp), TLS version (_https._tcp), both, neither (web), etc.

Further, the protocol needs to define how HASTLS records coexist with SRV records.  For instance, if there is a _http._tcp record and a _https._tcp record, what does a given HASTLS record mean?  Would a triple "0 443 1" imply that _http._tcp SRV records shouldn't exist?

And more fundamentally, is a HASTLS record any more useful than the information gleaned by querying SRV records in the first place?

Cheers,
-Benson

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Jan 2011 10:46:48 -0800

On 1/25/11 11:11 PM, Patrik Fältström wrote:
> 1. Have I understood it correct if the client by using this RR can
> refuse to fall back to insecure connection for "communication using
> HTTP"? I.e. it seems the RR is specifying whether fallback is
> possible to not only per port, which works when you have "STARTTLS"
> or similar, but not when fallback is between ports?

The intention is to tell a client that could fall back, regardless of if 
it on the same port (STARTTLS) or between ports (443 to 80), that the 
server offers the non-secured option. I can try to make this clearer in 
a future draft.

> 2. If so, the "input" to the query should in that case be not only
> the hostname, but the protocol and hostname, right? So one could use
> a prefix-based mechanism like _http._tcp.example.com. IN HASTLS 0 443
> 0

That might be good to do anyway. That is, having the query be in the 
same format as SRV queries, but with a HASTLS type, could give just the 
information wanted. The result could be an RRset with multiple HASTLS 
records.

> 3. I am always a bit nervous over RDATA that has variable length. Do
> you have an implementation of this so that you have tried to ensure
> "it works"?

No, and I think that the above proposal might allay your fears.

> Otherwise, as someone said, overall negotiation I think is

Great!

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 27 Jan 2011 11:54:57 -0700

I agree that this document is appropriate for the appsawg.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Jan 2011 11:20:12 -0800

> function to implementation.

At the time I wrote this, I thought that there would be agreement in the 
DNSEXT WG to help make sure that DNSSEC was used end-to-end. It now 
seems there is no interest in pursuing that. So, I will downgrade this 
to a security consideration that says that relying on this 
security-related information, if gotten insecurely, gives an attacker a 
different way to perform a downgrade attack.

> server through DNS is expressing its capabilities to the client, so when

No client *needs* to use HASTLS: it is useful for making decisions when 
things go wrong. A HASTLS query might be made by a CSO client when they 
can't reach a site they thought had a TLS service (such as if they had 
been there before); a CFB client would want to do a HASTLS query before 
falling back to insecure; a CIO client might do a HASTLS query before 
trying to communicate at all.

> I recommend something like (servicename-or-number/protocol TLS=port#

See my earlier response to Patrik.

> have to take care that a label not contain all numbers (I seem to recall

I think that returning an RRset would solve both your concern and 
Patrik's concern about variable-length responses.

> query for a bunch of records (TCP, DTLS, SCTP, etc.).

That is certainly an option. I tend to shy away from kitchen-sink 
approaches, but doing so means that there then needs to be many more 
RRtypes. This balance is based on preference, not protocol needs. The WG 
should certainly be the ones to say which style preference should be 
used in the protocol.

> 6.  Along these lines we should view this as an evolution of SRV.

Errr, just to be clear: are you proposing that this be an update to RFC 
2782? If so, please give a straw-man for how that would work. I don't 
see how SRV records are extensible.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 27 Jan 2011 22:08:29 +0100

Paul,

Just on this point:

> Errr, just to be clear: are you proposing that this be an update to
> RFC 2782? If so, please give a straw-man for how that would work. I
> don't see how SRV records are extensible.
>

Were there a way to capture SRV functionality while offering the HASTLS
capability, then we could deprecate SRV.  I would only recommend doing
so, however, for a more generalized approach.  I think you're really
quite close to this already, especially given your answer to Patrik
(which I liked).

Eliot

---

From: Benson Schliesser <[email-masked]>
Date: Wed, 26 Jan 2011 00:12:00 -0800

Cheers,
-Benson

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 27 Jan 2011 16:39:02 -0800

(sorry for resending my previous note, by accident...)

> quite close to this already, especially given your answer to Patrik

Of course, SRV could be deprecated if its capability is performed by the HASTLS mechanism.  But "service discovery" is one thing, and "TLS fallback indication" is another.  In terms of a more generalized approach, creating SRV++ would be a better way to think of the problem.

Cheers,
-Benson