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

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 18 September 2014 09:25 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3BE1A86F8; Thu, 18 Sep 2014 02:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.554
X-Spam-Level:
X-Spam-Status: No, score=-8.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 opI3eG8_xo89; Thu, 18 Sep 2014 02:25:43 -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 4B71B1A86F3; Thu, 18 Sep 2014 02:25:43 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8I9Pa0n029198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 18 Sep 2014 05:25:37 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8I9PXZ5027766 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2014 05:25:35 -0400
Message-ID: <1411032333.18523.18.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Tom Ritter <tom@ritter.vg>
Date: Thu, 18 Sep 2014 11:25:33 +0200
In-Reply-To: <CA+cU71kRu2bWAtBvBCKNL29pvq=Hnj2Mx70yecS8NBTy_Aj=2A@mail.gmail.com>
References: <CAMm+Lwis74P+H1tiG+beRwqfejkRUrjwt82OLpPokJ0jRx_S8w@mail.gmail.com> <1409931283.1731.16.camel@dhcp-2-127.brq.redhat.com> <CA+cU71kRu2bWAtBvBCKNL29pvq=Hnj2Mx70yecS8NBTy_Aj=2A@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.23
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cSdX1hfu2fxCW_kteFATHverVkY
Cc: "pkix@ietf.org" <pkix@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] New version of the TLS feature draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Thu, 18 Sep 2014 09:25:44 -0000

On Sat, 2014-09-13 at 20:20 -0500, Tom Ritter wrote:
> On 5 September 2014 10:34, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> > 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?
> 
> Section 3.1.1 specifies "a server MUST return a valid OCSP token".   I
> would consider an expired ocsp staple to not actually be valid.  I
> would refer to it as expired, with the implication that the signature
> is correct, because if it wasn't a person probably would have said
> that in addition to describing it as expired.

That's pretty sketchy. OCSP responses have a recommended validity
interval, this is not the same as X.509 certificate expiration. I'm not
sure what popular browsers do with responses received by the server that
are outside the validity period, but I would be very surprised if they
dropped the connection. If in this document it is assumed that responses
not within the recommended interval should cause a TLS connection
failure, it should be explicit.

regards,
Nikos