IETF Logo Mail Archive

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

"Miller, Timothy J." <tmiller@mitre.org> Mon, 29 March 2010 14:28 UTC

Return-Path: <tmiller@mitre.org>
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 4EC7E3A68D8; Mon, 29 Mar 2010 07:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.291
X-Spam-Level:
X-Spam-Status: No, score=-5.291 tagged_above=-999 required=5 tests=[AWL=0.178, 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 aomfvIFG3360; Mon, 29 Mar 2010 07:28:56 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 643E13A67B0; Mon, 29 Mar 2010 07:28:56 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2TETOb3013488; Mon, 29 Mar 2010 10:29:24 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2TETOqQ013480; Mon, 29 Mar 2010 10:29:24 -0400
Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 29 Mar 2010 10:29:23 -0400
From: "Miller, Timothy J." <tmiller@mitre.org>
To: "'Kemp, David P.'" <DPKemp@missi.ncsc.mil>, "pkix@ietf.org" <pkix@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Date: Mon, 29 Mar 2010 10:29:23 -0400
Thread-Topic: [pkix] Possible revocation delay issue with TLS stapling
Thread-Index: AcrNK4YIBZ+TXVLfSSiIWZLv/SVipgCFPNTQAADWU9AAAf/wcA==
Message-ID: <17FD76C1ECD0AB49817637E21809ABF907FAA70D29@IMCMBX2.MITRE.ORG>
References: <op.u95kjftmkvaitl@lessa-ii><17FD76C1ECD0AB49817637E21809ABF907FAA70D19@IMCMBX2.MITRE.ORG><op.u9610i13kvaitl@lessa-ii> <17FD76C1ECD0AB49817637E21809ABF907FAA70D24@IMCMBX2.MITRE.ORG> <201003291354.o2TDsYbP026924@stingray.missi.ncsc.mil>
In-Reply-To: <201003291354.o2TDsYbP026924@stingray.missi.ncsc.mil>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 14:28:57 -0000

Well, the OCSP responder *could* be the CA, in which case assurance does go back to the revocation authority.  I don't think any PKIs beyond the smallest follow this trust model, but it's there.

>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.

I've been thinking about using RSS for delta CRL and/or full CRL publication.  That would get you the semantics, but the overhead is still a problem.

-- Tim


>-----Original Message-----
>From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
>Kemp, David P.
>Sent: Monday, March 29, 2010 8:55 AM
>To: pkix@ietf.org; tls@ietf.org
>Subject: Re: [pkix] Possible revocation delay issue with TLS stapling
>
>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."
>
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix

v2.23.0 | Report a Bug | By Email