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

Patrik Fältström <> Wed, 26 January 2011 07:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADFEC3A6948 for <>; Tue, 25 Jan 2011 23:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.159
X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6zIA1+hJc6pm for <>; Tue, 25 Jan 2011 23:08:25 -0800 (PST)
Received: from ( [IPv6:2a02:80:3ffe::39]) by (Postfix) with ESMTP id 1EB943A6837 for <>; Tue, 25 Jan 2011 23:08:25 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF3A8F4D5372; Wed, 26 Jan 2011 08:11:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AV+bmASVeU4D; Wed, 26 Jan 2011 08:11:23 +0100 (CET)
Received: from ( []) (Authenticated sender: paf01) by (Postfix) with ESMTP id C5284F4D52DB; Wed, 26 Jan 2011 08:11:22 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Patrik Fältström <>
In-Reply-To: <>
Date: Wed, 26 Jan 2011 08:11:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Paul Hoffman <>
X-Mailer: Apple Mail (2.1082)
Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Jan 2011 07:09:11 -0000

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


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.
> 	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:
> _______________________________________________
> apps-discuss mailing list