Re: [secdir] [dane] SecDir Review of draft-ietf-dane-ops-12

Paul Wouters <paul@nohats.ca> Mon, 13 July 2015 03:37 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366521A036C; Sun, 12 Jul 2015 20:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 QhMSrGZKdNio; Sun, 12 Jul 2015 20:37:12 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64E11A036B; Sun, 12 Jul 2015 20:37:11 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mV9dd49G7z20h; Mon, 13 Jul 2015 05:37:09 +0200 (CEST)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=R21MlG5w
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cQc7989KHoBK; Mon, 13 Jul 2015 05:37:08 +0200 (CEST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Jul 2015 05:37:08 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C2BB1800EF; Sun, 12 Jul 2015 23:37:07 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1436758627; bh=wmp/36CtovY312LYOcFNVmQzhyvMqdwOPwgr/mPFxdA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=R21MlG5wolAnJKO+w9x1l/oztwImaLZlCKWHTvom/UZVXamVbmhQ3haK0IlPvpzGF SU9g09p8OMCSI+ae/ca0h43XzHGEyg02afnGfRhvon1J+V0HM6ezJgBwMpBIN0G6DS piv3KQZ2n/nDd69u61cb/eTciofY9iRiRtT1UFjQ=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6D3b7MH014969; Sun, 12 Jul 2015 23:37:07 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Sun, 12 Jul 2015 23:37:07 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: dane@ietf.org
In-Reply-To: <20150713032950.GI28047@mournblade.imrryr.org>
Message-ID: <alpine.LFD.2.11.1507122331280.3522@bofh.nohats.ca>
References: <C0E0A32284495243BDE0AC8A066631A818C43CD4@szxeml557-mbs.china.huawei.com> <20150711164349.GP28047@mournblade.imrryr.org> <alpine.LFD.2.11.1507122242200.3522@bofh.nohats.ca> <20150713032950.GI28047@mournblade.imrryr.org>
User-Agent: Alpine 2.11 (LFD 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/TM7fX4mto9CD_Eu0ut2OooZpBBo>
Cc: "iesg@ietf.org" <iesg@ietf.org>, IETF Security Directorate <secdir@ietf.org>
Subject: Re: [secdir] [dane] SecDir Review of draft-ietf-dane-ops-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2015 03:37:13 -0000

On Mon, 13 Jul 2015, Viktor Dukhovni wrote:

>> CT auditors log EE-certs. Checking the CT logs also provides a way to
>> signal rogue EE-certs to the original webserver via a gossip/client
>> protocol. So I would not say Usage 3 should never check the CT logs.
>
> DANE-EE(3) certs are often self-signed, and there's no way to
> control the "spam" problem on the CT logs with DANE-EE(3).

You don't know what audit logs will use for policies. Perhaps some
audit logs will be dedicated to only self-signed certs. I do not
think the dane document should dictate CT behaviour.

> Furthermore such a certificate is only ever "rogue" if DNSSEC is
> compromised to publish rogue TLSA RRs.

Not if they use a CT log for prepublishing somehow. Although that is
unlikely to happen with SCT's without a CA, I still think you should
not make those decisions on this document.

>> I don't think that whether or not public/private CA's are in used in
>> the TLSA record matters. A client that wants to confirm an EE-cert
>> via DNSSEC _and_ CT should be able to do so.
>
> Perhaps if it were possible, but I'm afraid it is not.  From the
> CT FAQ:

> Thus CT logs will not accept self-signed, domain-issued, ...

The CT FAQ is not an IETF document.

> You're misreading the text.  It is warning server operators that
> "3 0 0" is less suitable for serving RPK clients (if that's what

We disagree on the concept of "RPK" clients.

>> I am confused. If DANE is only talking about how to verify a certain
>> certificate received over TLS, I do not think this document should
>> modify the TLS protocol with respect to SNI. It's out of scope.
>
> You're confused.  The server is free to ignore the client's SNI
> extension when it has a single certificate that works for all hosted
> domains, because clients authenticate the server via the certificate
> or key digest, and don't care about what name is in the certificate.
> We're not modifying TLS, we're explaining that the server is free
> to ignore the client's SNI extension.

How is that not modifying TLS server behaviour?

Paul