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

[Eliot Lear <[e-mail]>]

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:
> 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 <[e-mail]> 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:
>> http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-03.txt
>> _______________________________________________
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>