IETF Logo Mail Archive

Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling

"Kemp, David P." <DPKemp@missi.ncsc.mil> Mon, 29 March 2010 13:54 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730F73A6A1A; Mon, 29 Mar 2010 06:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.633
X-Spam-Level:
X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
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 ntgf4tJpjp-G; Mon, 29 Mar 2010 06:54:28 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 3E4473A6A67; Mon, 29 Mar 2010 06:54:07 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 29 Mar 2010 09:54:33 -0400
Message-ID: <201003291354.o2TDsYbP026924@stingray.missi.ncsc.mil>
In-Reply-To: <17FD76C1ECD0AB49817637E21809ABF907FAA70D24@IMCMBX2.MITRE.ORG>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [pkix] Possible revocation delay issue with TLS stapling
thread-index: AcrNK4YIBZ+TXVLfSSiIWZLv/SVipgCFPNTQAADWU9A=
References: <op.u95kjftmkvaitl@lessa-ii><17FD76C1ECD0AB49817637E21809ABF907FAA70D19@IMCMBX2.MITRE.ORG><op.u9610i13kvaitl@lessa-ii> <17FD76C1ECD0AB49817637E21809ABF907FAA70D24@IMCMBX2.MITRE.ORG>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: pkix@ietf.org, tls@ietf.org
X-OriginalArrivalTime: 29 Mar 2010 13:55:33.0875 (UTC) FILETIME=[807C7C30:01CACF47]
Subject: Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Mon, 29 Mar 2010 13:54:29 -0000

That only gets you halfway there, since the nonce only ensures freshness
back to the OCSP responder, not the revocation authority.  The responder
itself can get revocation updates using any of the strategies you
mentioned (on every query - e.g. database backend, only after CRL
nextUpdate, somewhere in between, only after somewhere beyond
nextUpdate). 

If you *really, really* care, insist on CRLs.  But that would require
reasonable-sized CRLs (10Kb) with reasonably short nextUpdate (24h),
neither of which DoD currently produces.

It would also help to have a low-overhead (UDP-based with DTLS symmetric
integrity) CRL query protocol with an "I have this one, send me a newer
one if it exists" semantics.

Dave


-----Original Message-----
From: Miller, Timothy J

Which throws us back on "If you *really* care, insist on nonces."

v2.23.0 | Report a Bug | By Email