Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3

Stephen Kent <kent@bbn.com> Tue, 07 July 2015 15:38 UTC

Return-Path: <kent@bbn.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6834D1A8932 for <trans@ietfa.amsl.com>; Tue, 7 Jul 2015 08:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 Buqa8Z3waFrk for <trans@ietfa.amsl.com>; Tue, 7 Jul 2015 08:38:24 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC08C1A88FD for <trans@ietf.org>; Tue, 7 Jul 2015 08:38:24 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:36019 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1ZCUwx-000C5H-Ht for trans@ietf.org; Tue, 07 Jul 2015 11:38:23 -0400
From: Stephen Kent <kent@bbn.com>
To: trans@ietf.org
References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> <067.3ff0deebd05d8bff20fd4c0512edb4c3@tools.ietf.org> <559A95C7.3010107@bbn.com> <CABrd9SS1nVbYZm0L4BhtnvuWH-usU-_vHCT8EPKsvGCLovQ5AQ@mail.gmail.com> <559ACA98.2040509@bbn.com> <CABrd9STispeyFh+-bYJE7OSZ5qyWtuEraO9KM8FfF2p2jSk47Q@mail.gmail.com>
Message-ID: <559BF26F.4010407@bbn.com>
Date: Tue, 07 Jul 2015 11:38:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CABrd9STispeyFh+-bYJE7OSZ5qyWtuEraO9KM8FfF2p2jSk47Q@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/V1p_3vLj5sP-6dZq2P_xZ1n80ik>
Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2015 15:38:26 -0000

Ben,

> A certificate not accompanied by an SCT is not CT compliant.
> This seems redundant: I would've thought that in general everything in
> an RFC only applies to things that are compliant with that RFC. But if
> the WG wants I don't really mind either way.
I prefer the wording I suggested because it emphasizes the status of the 
cert relative
to this spec, rather than intimating any TLS client behavior.
>
> OK, I get your point here, and I am happy to go either way:
>
> a) Update TLS to require CT, or
that's not what I meant to suggest. I don't think CT is destined to become
a mandatory aspect of TLS; it's an optional feature.
> b) Update the I-D to say something like "CT compliant TLS clients" or
> as you use below "TLS clients claiming conformance with CT", which
> presumably does not update TLS?
TLS is the definitive spec for the messages exchanged during its 
handshake. So
the specs in Section 3.4 represent an update to TLS (1.2). That does not 
make
support for CT mandatory, but it informs implementers of the new TLS 
extensions
defined here and the processing they imply.

Steve