[keyassure] Binding to full TLS encapsulation or STARTTLS

Matt McCutchen <matt@mattmccutchen.net> Sun, 13 February 2011 18:14 UTC

Return-Path: <matt@mattmccutchen.net>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CBF3A6ABD for <keyassure@core3.amsl.com>; Sun, 13 Feb 2011 10:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11]
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 CKkRQxnluMPW for <keyassure@core3.amsl.com>; Sun, 13 Feb 2011 10:14:51 -0800 (PST)
Received: from homiemail-a1.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 5521A3A67BD for <keyassure@ietf.org>; Sun, 13 Feb 2011 10:14:51 -0800 (PST)
Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 2494534806A for <keyassure@ietf.org>; Sun, 13 Feb 2011 10:15:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns; s=mattmccutchen.net; b=U6pY7W5 8MY+8J/gGsOicWcj33PRAhBMkFq8G6OjToCbjQS8FoRoFsdXsincefHWf7T/dCIp a+6udxPQM6pKxRLXWIpwp6XMq7M8SWVS9nagnEIWGqUgjUSM7fuppUZ2isEdvxoS ro/jqfOexgc5xv6X/7LUQHLuos95e16Dp5qY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:content-type:date:message-id:mime-version: content-transfer-encoding; s=mattmccutchen.net; bh=Rol6a+izD55VO iCBHjg9Zp68xIA=; b=YiQzUysn4bM+zXvOQfs+Ss6uFQ1mDQfUOQG3C1QH4UIfd 1CKloYnI414qyhNcujIT4XJCTOUbv4cCocNYtt+boofT4hjFlEQQjtHiYcFvp5WX /PPw7VwDd5L4Pb3HxdT9A5SiVoe5Jm+G8CXcK75B/s/eoZ9J67jv0+8fk1RUg8=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id E3B53348062 for <keyassure@ietf.org>; Sun, 13 Feb 2011 10:15:11 -0800 (PST)
From: Matt McCutchen <matt@mattmccutchen.net>
To: keyassure <keyassure@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 13 Feb 2011 13:15:10 -0500
Message-ID: <1297620910.1890.28.camel@mattlaptop2.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2
Content-Transfer-Encoding: 7bit
Subject: [keyassure] Binding to full TLS encapsulation or STARTTLS
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Feb 2011 18:14:52 -0000

I realized that TLSA as we are currently discussing does not bind keys
to the use of full TLS encapsulation or STARTTLS.  I'm thinking this is
OK because it would be pretty ridiculous to multiplex different services
based on the use of full encapsulation or STARTTLS, and clients
generally do not ascribe security significance to the use of one or the
other.  E.g., if I bind a key to _3141._tcp.example.com for a service
that uses STARTTLS, I can't think of any scenario in which a client
trying to use full encapsulation would be harmed if a MITM allowed it to
succeed by performing the STARTTLS part directly with the server.  It
might be nice to prevent web browsers from talking to STARTTLS services,
but that would be far from a complete solution to the problem of
browsers being a loose cannon for arbitrary connections, nor is it our
responsibility to solve that problem here.

Sanity check?

-- 
Matt