IETF Logo Mail Archive

Re: [keyassure] TLSA and HASTLS

Paul Hoffman <paul.hoffman@vpnc.org> Fri, 17 December 2010 19:30 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 9733F3A6BDD for <keyassure@core3.amsl.com>; Fri, 17 Dec 2010 11:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.572
X-Spam-Level:
X-Spam-Status: No, score=-101.572 tagged_above=-999 required=5 tests=[AWL=0.474, 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 WEdgmqdPW7cr for <keyassure@core3.amsl.com>; Fri, 17 Dec 2010 11:30:41 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C724A3A6BDB for <keyassure@ietf.org>; Fri, 17 Dec 2010 11:30:41 -0800 (PST)
Received: from [10.20.30.150] (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 oBHJWR9A008097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 12:32:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240854c93169ed0398@[10.20.30.150]>
In-Reply-To: <alpine.LFD.1.10.1012171356510.12352@newtla.xelerance.com>
References: <20101213220001.24500.52050.idtracker@localhost> <alpine.LFD.1.10.1012141956500.21359@newtla.xelerance.com> <alpine.LFD.1.10.1012171255280.12352@newtla.xelerance.com> <p0624084bc9315b499533@[10.20.30.150]> <alpine.LFD.1.10.1012171356510.12352@newtla.xelerance.com>
Date: Fri, 17 Dec 2010 11:32:26 -0800
To: Paul Wouters <paul@xelerance.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: keyassure@ietf.org
Subject: Re: [keyassure] TLSA and HASTLS
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: Fri, 17 Dec 2010 19:30:42 -0000

At 2:07 PM -0500 12/17/10, Paul Wouters wrote:
>On Fri, 17 Dec 2010, Paul Hoffman wrote:
>
>>>Could we add something like:
>>>
>>>	If a client detects a validated TLSA record, it MUST only use https (not http)
>>>	to connect to the target site to prevent SSL stripping attacks.
>>
>>Probably not. That is, if the user is not going to TLS (because the server doesn't do TLS or a MITM has done a downgrade to non-TLS), they should not be looking for TLSA records.
>>
>>The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case) and hopefully by draft-hoffman-server-has-tls (depending on how the WEBSEC WG moves forwards).
>
>Hmm, so draft-hoffman-server-has-tls-01 defines a HASTLS record. Execsum:
>
>	www.example.com IN HASTLS (25 25 0 443)
>
>But we have no method defined anyway to get all this information at once. So now this becomes two full roundtrip DNS queries
>to get enough information about the pubkey used on a website.

Not at all. If you are about to do TLS and only TLS, then you don't need to query for HASTLS: it is only if you want to do TLS but cannot get there that you need to do HASTLS.

> Is there any work being done on optimising this with an EDNS
>option?

It's a thought, but one that has not garnered much interest in the past.

>Is there any reason why the TLSA and HASTLS records could not be merged into one RRTYPE to save a roundtrip?
>Why aren't we doing something like:
>
>	www.example.com IN HASTLS (25 25 KeyType FingerPrint 0 443 KeyType FingerPrint)

Because the "this host serves TLS and non-TLS" and "when we serve TLS, this is the key we will use" semantics are orthogonal. Having orthogonal semantics in the same record often leads to implementations that do not interoperate.

--Paul Hoffman, Director
--VPN Consortium

v2.23.0 | Report a Bug | By Email