Re: [pkix] [TLS] New version of the TLS feature draft

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 05 September 2014 15:34 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1259E1A0739; Fri, 5 Sep 2014 08:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.57
X-Spam-Level:
X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 OGKEqXiJtkbh; Fri, 5 Sep 2014 08:34:50 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 C1E0B1A071D; Fri, 5 Sep 2014 08:34:50 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s85FYjqM032302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 Sep 2014 11:34:45 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s85FYhx8022346 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2014 11:34:44 -0400
Message-ID: <1409931283.1731.16.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 05 Sep 2014 17:34:43 +0200
In-Reply-To: <CAMm+Lwis74P+H1tiG+beRwqfejkRUrjwt82OLpPokJ0jRx_S8w@mail.gmail.com>
References: <CAMm+Lwis74P+H1tiG+beRwqfejkRUrjwt82OLpPokJ0jRx_S8w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/nRQTqBb3_7Z8zAvkohcMlEg05F8
X-Mailman-Approved-At: Mon, 08 Sep 2014 11:59:01 -0700
Cc: "pkix@ietf.org" <pkix@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [pkix] [TLS] New version of the TLS feature draft
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Sep 2014 15:34:52 -0000

On Wed, 2014-09-03 at 16:40 -0400, Phillip Hallam-Baker wrote:
> This draft is just a bit of wiring that allows TLS clients to make
> intelligent and efficient hardfail decisions when a TLS server
> supports OCSP stapling.
> 
> OCSP stapling has been supported for some time and when supported by a
> server allows a client to obtain OCSP status information direct from
> the server rather than going hunting for it from a distribution point.
> 
> What makes OCSP stapling rather less useful than it should be is that
> a TLS client does not know whether it should expect a TLS token or
> not. So the absence of an OCSP token could be because the server does
> not support stapling or could be because the CA has revoked the
> certificate with extreme prejudice because it is being used to commit
> fraud against people visiting the corresponding Web site.
> The TLS feature extension allows a certificate to state which TLS
> features a server using the cert MUST support. This closes the door on
> the downgrade attack.

I don't see how it does close the door. What should the client do if the
server administrator sets up an old version of a valid ocsp staple? This
case is not discussed in the security considerations at all.

regards,
Nikos