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

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 27 January 2011 19:17 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F753A69F0 for <apps-discuss@core3.amsl.com>; Thu, 27 Jan 2011 11:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.744
X-Spam-Level:
X-Spam-Status: No, score=-101.744 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oG8AYz-ewWx for <apps-discuss@core3.amsl.com>; Thu, 27 Jan 2011 11:17:09 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D7DEC3A69ED for <apps-discuss@ietf.org>; Thu, 27 Jan 2011 11:17:09 -0800 (PST)
Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0RJKDYH070520 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Thu, 27 Jan 2011 12:20:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D41C56C.8060900@vpnc.org>
Date: Thu, 27 Jan 2011 11:20:12 -0800
From: Paul Hoffman <paul.hoffman@vpnc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4D33AC5F.3010609@vpnc.org> <AANLkTim5LpgqM5F2Zb_s+O4Jv8vrF+dcrnr3DpCMAJ6C@mail.gmail.com> <4D3EEE94.2090801@cisco.com>
In-Reply-To: <4D3EEE94.2090801@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2011 19:17:10 -0000

On 1/25/11 7:39 AM, Eliot Lear wrote:
> 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.

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.

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

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.

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

See my earlier response to Patrik.

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

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

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

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.