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

Benson Schliesser <> Wed, 26 January 2011 08:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3727F3A6951 for <>; Wed, 26 Jan 2011 00:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zClISQUZfvIB for <>; Wed, 26 Jan 2011 00:09:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B84833A6958 for <>; Wed, 26 Jan 2011 00:09:06 -0800 (PST)
Received: by pxi6 with SMTP id 6so31473pxi.31 for <>; Wed, 26 Jan 2011 00:12:06 -0800 (PST)
Received: by with SMTP id q1mr35503wfq.344.1296029526073; Wed, 26 Jan 2011 00:12:06 -0800 (PST)
Received: from [] ( []) by with ESMTPS id w22sm19922912wfd.7.2011. (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 00:12:04 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Benson Schliesser <>
In-Reply-To: <>
Date: Wed, 26 Jan 2011 00:12:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Barry Leiba <>
X-Mailer: Apple Mail (2.1082)
X-Mailman-Approved-At: Wed, 26 Jan 2011 08:17:30 -0800
Cc: Paul Hoffman <>,
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 08:09:15 -0000

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?


On Jan 24, 2011, at 6:35 PM, Barry Leiba wrote:

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