IETF Logo Mail Archive

Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

James Cloos <cloos@jhcloos.com> Sat, 31 May 2014 19:05 UTC

Return-Path: <cloos@jhcloos.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACB81A007B for <dane@ietfa.amsl.com>; Sat, 31 May 2014 12:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Level:
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhVtaD1B64sL for <dane@ietfa.amsl.com>; Sat, 31 May 2014 12:05:24 -0700 (PDT)
Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29791A0079 for <dane@ietf.org>; Sat, 31 May 2014 12:05:24 -0700 (PDT)
Received: by ore.jhcloos.com (Postfix, from userid 10) id 4F63E1DE9E; Sat, 31 May 2014 19:05:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1401563119; bh=QAYp1z+bF6MKTL23n/dZTplVeBBHf78gTAvkgt8+Sm4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=aGn+9WcVKn3kArV9yo+w5R0fpgPJN8otjR6S/RxwzR6tSb/bnHUpdlATIlRTEMje2 6RvPT8tyB7009owfoY4NpILmf6YO30OnjiSWrC24URosQ2H/pzlyznPA36PdaFdPx7 ynYtzBqYPTTlvDnxdV1rkVPbkA3pHS6NSPp9DzyE=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 4CDF26001E; Sat, 31 May 2014 18:58:08 +0000 (UTC)
From: James Cloos <cloos@jhcloos.com>
To: Viktor Dukhovni <viktor1dane@dukhovni.org>
In-Reply-To: <20140531011048.GE27883@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sat, 31 May 2014 01:10:48 +0000")
References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <alpine.LFD.2.10.1405291257210.14277@bofh.nohats.ca> <20140529180356.GL27883@mournblade.imrryr.org> <m3a99zgkdk.fsf@carbon.jhcloos.org> <20140530192840.GC27883@mournblade.imrryr.org> <m3mwdyg7do.fsf@carbon.jhcloos.org> <20140531011048.GE27883@mournblade.imrryr.org>
User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2014 James Cloos
OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
Date: Sat, 31 May 2014 14:58:08 -0400
Message-ID: <m3r439bwrq.fsf@carbon.jhcloos.org>
Lines: 18
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:140531:viktor1dane@dukhovni.org::0bm5clE854joFBBR:000000000000000000000000000000000000ietUX
X-Hashcash: 1:30:140531:dane@ietf.org::sN8JEI/W7+pmZXRS:000kyRH3
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/rgnh6R_RF2PYHTiyr1d3Yd86eFE
Cc: dane@ietf.org
Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 May 2014 19:05:26 -0000

>>>>> "VD" == Viktor Dukhovni <viktor1dane@dukhovni.org> writes:

VD> If the TLSA records don't include any [3-0-0 or 3-1-x], or are
VD> mixed, the client must not negotiate "oob public key".

That is a valid point, but if they are mixed, the clients can try, and
if the offered key doesn't match the suitable tlsas, it can drop the
connection and try again without specifying the extension.

When properly configured, if the server's only current cert(s) is full,
then the server should not agree to the tls extension.  The need to drop
and restart should be rare.

-JimC

P.S.  Sorry for replying yesterday before I read your corretion re 3-0-0.
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

v2.23.0 | Report a Bug | By Email