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

"Dr. Massimiliano Pala" <massimiliano.pala@gmail.com> Tue, 11 November 2014 02:21 UTC

Return-Path: <massimiliano.pala@gmail.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 9101E1AD445; Mon, 10 Nov 2014 18:21:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Level:
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001, T_HK_NAME_FM_DR=0.01] autolearn=no
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 fQyVx7sveF7e; Mon, 10 Nov 2014 18:21:16 -0800 (PST)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03861AD441; Mon, 10 Nov 2014 18:21:15 -0800 (PST)
Received: by mail-wg0-f41.google.com with SMTP id k14so10429068wgh.28 for <multiple recipients>; Mon, 10 Nov 2014 18:21:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eF84d63HUe946qA64CZBbz0A9K7G7JYtYF4DTdzLdvM=; b=URPkg8wRJv/PrBtXcVHVU1w+KQRS1BktZuZafpY7nkw1qPCazgg1eg+tRA3KYuIfeI Rot/uMfBQZfpDz8u6NH+FCqRUAKwu8wai2up08a65llMLldvtoBG6rxKu7NWwrXJyfyQ CsGe24EZJ7S+Lye+Tij+6eUZ+EuBKYH5+yFQ0H7KLMWjBjuCJAR0jjksEnG9rorTDmm8 r0bO0QbX2h+UZSJ5TeIgvjCOuQSCyu5Hn4JEqIC5NBjXEtA6ribYTuBnD0eNfcUk3y3n rt/53rqV308lldZfPDBvQq7yC3KY/0N240E49khXhkcdrnljhKSNkYtoauaWA/4pUQLg 8QRQ==
X-Received: by 10.194.92.82 with SMTP id ck18mr48914104wjb.103.1415672474802; Mon, 10 Nov 2014 18:21:14 -0800 (PST)
Received: from iMassi.local ([2001:67c:1231:998:2daf:6f04:992b:d693]) by mx.google.com with ESMTPSA id ft8sm2421452wjb.17.2014.11.10.18.21.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 18:21:14 -0800 (PST)
Message-ID: <54617296.5070600@gmail.com>
Date: Mon, 10 Nov 2014 16:21:10 -1000
From: "Dr. Massimiliano Pala" <massimiliano.pala@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "pkix@ietf.org" <pkix@ietf.org>
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> <1411032333.18523.18.camel@dhcp-2-127.brq.redhat.com> <CAMm+Lwj+n9HVCBToUYeS+FLctq+pTG99i+EeAmtThPq0AyJtvg@mail.gmail.com> <1411051138.18523.42.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1411051138.18523.42.camel@dhcp-2-127.brq.redhat.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bkON2RV480Do3BQwpNs4IPXP-3c
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [pkix] 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: Tue, 11 Nov 2014 02:21:18 -0000

Hi all,

I would just like to point out that stapling is not the only 
distribution mechanism for OCSP responses -  a useful optimization for
high-volume servers, but still an optimization: i.e. the server is not 
the sole (or authoritative) source of revocation information: that is 
the CA/OCSP server role.

The application (and it is NOT only browsers!) can always reference the 
AIA:OCSP URI in the certificate for accessing the OCSP response. Maybe 
it should be mentioned/noted that the application could decide to (a) 
directly abort the connection or (b) use the default PKIX/OCSP response 
protocol as backup.

Cheers,
Max


> On Sep 18, 2014, at 4:38 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>
> On Thu, 2014-09-18 at 07:57 -0400, Phillip Hallam-Baker wrote:
>
>>>> 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.
>> Given that we currently have a situation where the vast majority of
>> Web browsers are not PKIX compliant and ignore revocation information
>> completely and Web browsers are only one PKIX application, I don't
>> think it is appropriate to use a MUST here to direct how invalid
>> status is handled.
>
> Maybe not, but it makes sense to define what is valid and invalid.
> The problem statement of this draft as you set it is to close a door on
> a "downgrade" attack where no OCSP response is sent. However, if you
> don't define what is a secure connection to a server that supports OCSP
> status request, how can you claim to fix an attack?
>
> regards,
> Nikos
>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix