Re: [TLS] Getting started, clock not set yet

Benjamin Kaduk <bkaduk@akamai.com> Tue, 09 August 2022 23:20 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3CBC159480 for <tls@ietfa.amsl.com>; Tue, 9 Aug 2022 16:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3NgtKcvXMSD for <tls@ietfa.amsl.com>; Tue, 9 Aug 2022 16:20:23 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 9DF17C157B57 for <tls@ietf.org>; Tue, 9 Aug 2022 16:20:21 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 279JT65A000580; Wed, 10 Aug 2022 00:20:21 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=g8MZYH3FdJDOBLjho++9vWjjKVyW/kri6zpQv5zhen0=; b=bSflDDzRJp0C1bbUTJZsa0wkytPuePrtoCbHLvpxFMRlDyjX8awMbmHSVW/ouZYn++xd rg9jB8JMexeYJjJCvWOtL6xTJeHzvt1CFuwnkM8wVYfWEWt8oFmInAXKq+ptFYZPU8w1 gsxh1KpkvtMOpOsRXPHDKeQX7A+kOTK5wDTEaoUW5VRMtzkOK0Xl2BoU67/QQoLE3t3Z Fy6etiQbvalg+Wv00YNyP2iZ2mOn9OXvi/ulHmO1BsGLBEZojVgcsDfeqaeK5WEikoi4 dT4vgbnSmPn6ju7zRNroJkZIoZSr1gn4ZqPWizsWGcUJ+pQCFv+nwzBTgEsrgsQKa6Yf HQ==
Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by mx0a-00190b01.pphosted.com (PPS) with ESMTPS id 3huwsc9uw0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Aug 2022 00:20:20 +0100
Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.17.1.5/8.17.1.5) with ESMTP id 279JWdDm010662; Tue, 9 Aug 2022 19:20:02 -0400
Received: from email.msg.corp.akamai.com ([172.27.50.200]) by prod-mail-ppoint7.akamai.com (PPS) with ESMTPS id 3huwu3gqt9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 Aug 2022 19:20:01 -0400
Received: from ustx2ex-dag4mb8.msg.corp.akamai.com (172.27.50.207) by ustx2ex-dag4mb2.msg.corp.akamai.com (172.27.50.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Tue, 9 Aug 2022 16:20:01 -0700
Received: from akamai.com (172.19.16.38) by ustx2ex-dag4mb8.msg.corp.akamai.com (172.27.50.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9 via Frontend Transport; Tue, 9 Aug 2022 16:20:00 -0700
Date: Tue, 09 Aug 2022 16:19:58 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20220809231957.GX3579@akamai.com>
References: <20220809044037.8332328C1CA@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <SY4PR01MB6251F7EDC97E18A897BC3E6CEE629@SY4PR01MB6251.ausprd01.prod.outlook.com> <CABcZeBM7Xo=yT4GDSAzRNfZYBDAyaT9yNahOuNY8YDvx1SH+Rw@mail.gmail.com> <CAChr6Sy0oLDM=HLPCVtZEZracoD0GamAzGEg0fesrXAMzpEiLA@mail.gmail.com> <CABcZeBNZxUdNTeFCEPgGwtfehV-5LgV86QOXBi+Nqn2A0d6WUA@mail.gmail.com> <CAChr6SyJ=5bcEtMZXpfM=0UsixR0P7111nV0onksYeedSVF_KA@mail.gmail.com> <CABcZeBPvJx1G5da8ceyYBxuxHv6NYFSD_L0Y=cLCf-1cFwweww@mail.gmail.com> <20220809230826.GW3579@akamai.com> <CABcZeBMELWTRC9Ox9zjNRJ+bcy=rFV7zWi-skZKs81ncTcKG0g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBMELWTRC9Ox9zjNRJ+bcy=rFV7zWi-skZKs81ncTcKG0g@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-09_05,2022-08-09_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 mlxscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208090086
X-Proofpoint-ORIG-GUID: Nsqe2SgnqzLUEQMNGcyuDaw9GP3L0wSl
X-Proofpoint-GUID: Nsqe2SgnqzLUEQMNGcyuDaw9GP3L0wSl
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-09_05,2022-08-09_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 spamscore=0 impostorscore=0 mlxlogscore=999 phishscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1015 bulkscore=0 suspectscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208090086
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TLXKoP_qSg8sDwqrGUEf_w1eICY>
Subject: Re: [TLS] Getting started, clock not set yet
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Aug 2022 23:20:27 -0000

On Tue, Aug 09, 2022 at 04:12:37PM -0700, Eric Rescorla wrote:
> n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
> 
> > On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote:
> > >
> > > Be that as it may, the browsers generally require conformance to the BRs
> > > (see, for
> > > instance
> > >
> > https://urldefense.com/v3/__https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypX3KAVLzA$
> >
> > > S 2.3,
> > >
> > https://urldefense.com/v3/__https://www.chromium.org/Home/chromium-security/root-ca-policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypXz_sK-Pc$
> >  S 1)
> > > so what the BRs say is relevant in this discussion.
> >
> > While it seems almost inevitable that the Web PKI will be used for some
> > deployments of NTS, it also seems that NTS as a protocol is quite
> > untethered to
> > browser behavior or the Web PKI.  So while I agree that the CABF BRs are
> > relevant, they probably ought not be treated as the sole authority.
> >
> 
> Fair enough. I would make several points:
> 
> 1. Peter's message was not qualified to NTS. He wrote
> "For commercial CAs, the expiry time is a billing mechanism, not a security
> mechanism. "
> 
> So I was attempting to respond to the bigger picture.

Ok.

> 2. It seems quite likely that many of the NTS certificates will be from
> WebPKI CAs,
> just because that's what's easy to get, and so you can't count on them
> providing
> revocation after expiry.

Agreed, that's my "almost inevitable".

> 3. Are you aware of some other set of rules for certificate issuance that
> require
> revocation after the certificate has expired?

No.
And to be honest I would be somewhat surprised to learn of one, since
one of the big gains of having an expiration at all (vs just tracking
revocation information) is to simplify the database of revocation information
by allowing for pruning after expiry.  Perhaps some sort of "official records"
system might need it, but that's pure speculation.

Private parties not part of a broader PKI can of course use whatever policies
and procedures they want.

-Ben