Re: [apps-discuss] APPSDIR review of draft-ietf-tls-multiple-cert-status-extension-05

"Yngve N. Pettersen" <yngve@spec-work.net> Wed, 10 April 2013 16:09 UTC

Return-Path: <yngve@spec-work.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693F621F9976; Wed, 10 Apr 2013 09:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlJ7REp7XnLg; Wed, 10 Apr 2013 09:09:49 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id BBFC621F9977; Wed, 10 Apr 2013 09:09:48 -0700 (PDT)
Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:51560 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <yngve@spec-work.net>) id 1UPxaj-0004Ft-MS; Wed, 10 Apr 2013 18:09:45 +0200
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Peter Saint-Andre" <stpeter@stpeter.im>
References: <5165610C.1020803@stpeter.im> <op.wvbvjzd83dfyax@killashandra.invalid.invalid> <51658870.8070806@stpeter.im>
Date: Wed, 10 Apr 2013 18:09:42 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.wvb1ugim3dfyax@killashandra.invalid.invalid>
In-Reply-To: <51658870.8070806@stpeter.im>
User-Agent: Opera Mail/12.15 (Win32)
X-Mailman-Approved-At: Wed, 10 Apr 2013 18:13:36 -0700
Cc: draft-ietf-tls-multiple-cert-status-extension.all@tools.ietf.org, The IESG <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-tls-multiple-cert-status-extension-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 16:09:50 -0000

Hi,

On Wed, 10 Apr 2013 17:42:40 +0200, Peter Saint-Andre <stpeter@stpeter.im>  
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Yngve!
>
> On 4/10/13 7:53 AM, Yngve N. Pettersen wrote:
>> Hi Peter and Bert,
>>
>> Thanks for the review.
>>
>> On Wed, 10 Apr 2013 14:54:36 +0200, Peter Saint-Andre
>> <stpeter@stpeter.im> wrote:
>>
>>> Bert Greevenbosch and I have been selected as the joint
>>> Applications Area Directorate reviewers for this draft (for
>>> background on AppsDir, please see ​
>>> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
>>>
>>>
> ).
>>>
>>> Please resolve these comments along with any other Last Call
>>> comments you may receive. Please wait for direction from your
>>> document shepherd or AD before posting a new version of the
>>> draft.
>>>
>>> Document: draft-ietf-tls-multiple-cert-status-extension-05 Title:
>>> The TLS Multiple Certificate Status Request Extension Reviewers:
>>> Bert Greevenbosch and Peter Saint-Andre Review Date: 10 April
>>> 2013 IESG Telechat Date: 2013-04-11 Summary: This draft is almost
>>> ready for publication; comments raised here are for the WG's
>>> consideration.
>>>
>>> Major Issues:
>>>
>>> none
>>>
>>> Minor Issues:
>>>
>>> (1) Maybe a server can maintain cached OCSP responses, e.g. until
>>> after the "nextUpdate" time has expired. Then the server would be
>>> able to use these cached responses instead of acquiring a new
>>> response from the OCSP-responders. (This mechanism is e.g.
>>> defined in [OCSP-MP]). With the new extension, multiple
>>> OCSP-responses from probably different OCSP servers could be
>>> cached. The client needs to verify that each of the OCSP response
>>> is still valid, e.g. that none of the OCSP-responses are too
>>> old.
>>>
>>> [OCSP-MP]: OMA Online Certificate Status Protocol (profile of
>>> [OCSP]) V 1.0, Open Mobile Alliance,
>>> URL:http://www.openmobilealliance.org/
>>>
>>> Would some text about cached OCSP responses be appropriate? (Of
>>> course nonces would make caching impossible, as each OCSP
>>> responder would need to sign the new nonce.)
>>
>> The server would not know if the client have cached the response,
>> and the client would not know if there is a newer response held by
>> the server.
>>
>> The client could leave the request for certificate status out of
>> the handshake, but that would mean that 1) it would not get any
>> updated responses, and 2) if the serve changed its certificate(s)
>> between the previous handshake and the current handshake, it would
>> also not get the new responses, since it did not signal the
>> willingness to receive them.
>>
>> Resolving of that lack of information would require some kind of
>> signaling mechanism, which I think is outside the scope of this
>> particular document.
>>
>> At present, discussion is underway in the TLS WG of adding such a
>> mechanism to the draft-ietf-tls-cached-info
>> <http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/>. If
>> implemented, that would resolve the signaling mechanism problem,
>> and combine it with a more general mechanism.
>
> Thanks for the pointer to draft-ietf-tls-cached-info. I suppose that,
> if implemented, it might lead to some changes in several TLS-related
> specs, including this one. Correct?

To the extent that there are changes, those would be documented in the  
cached-info spec, and would depend on the granularity at which data are  
cached.

There would be no change for implementations that does not include  
cached-info, even if the other party does implement it. Any changes would  
only apply when both parties implement cached-info.

>>> (2) Section 2.2, p.5:
>>>
>>> A zero-length "request_extensions" value means that there are no
>>> extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is
>>> not valid for the "Extensions" type).
>>>
>>> This text was copied from RFC 6066. It seems a bit cryptic, but
>>> I suppose it means that the "request_extensions" field does not
>>> exist at all, e.g. the "OCSPStatusRequest" struct only contains
>>> the "responder_id_list<0..2^16-1>"?
>>
>> The record would still contain two zero bytes to indicate the
>> length of the request_extensions vector (the length-field of the
>> vector is not part of the content); the zerolength ASN1.1 SEQUENCE
>> would require a non-zero-length request_extensions field since the
>> field would contain a <SEQUENCE-indication + 0 byte length field>
>> in ASN.1 DER encoding, which would likely be one or two bytes
>> long.
>
> Thanks for the clarification. Would it make sense to add a small note
> to draft-ietf-tls-multiple-cert-status-extension on this point?

I am inclined to think it is not necessary, as I think the requirements  
are clear from the syntax, particularly the use of the "opaque" type.  
Implementors need to be familiar with both TLS record syntax in order to  
write the code, and the content would have to be generated by some ASN.1  
generator code.

Errors in the first would in particular quickly run into problems with  
other implementations (unless it happens in the first implementation and  
that implementation gains major marketshare before the problem is  
discovered; which have happened in SSL/TLS history at least twice IIRC).  
Given that this record is already used in RFC 6066 which is deployed by  
many clients and servers, and I assume the code for this structure will be  
reused, I don't think we are going to see a problem.

However, I did decide to add "DER-encoded" in front of "zero-length ASN.1  
SEQUENCE" to indicate that we are talking about a payload.

>>> (3) Section 2.2, p.6:
>>>
>>> Note that a server MAY also choose not to send a
>>> "CertificateStatus" message, even if it has received a
>>> "status_request_v2" extension in the client hello message and has
>>> sent a "status_request_v2" extension in the server hello
>>> message.
>>>
>>> In essence, this says that it is optional for the server to send
>>> the "CertificateStatus" message. What are the types of conditions
>>> under which it is reasonable to not send the "CertificateStatus"
>>> message?
>>
>> The supporting server might not yet have downloaded an OCSP
>> response. That is, for example, the case with nginx versions able
>> to use RFC 6066 OCSP Stapling. Those servers also have a bug which
>> makes them forward an expired OCSP response while they are fetching
>> the new one, rather than discarding it.
>>
>> In such cases the server can either wait until it receive the
>> response (which might mean a long wait for the client if the
>> responder is slow), or it can leave out the status message in
>> connections it is establishing until it have received the OCSP
>> response.
>
> That makes sense. Explaining that in the spec might make sense, since
> otherwise implementers might think there are other good reasons to not
> send the "CertificateStatus" message.

However, a general reason for not sending the actual message is that the  
server might know that it can send the message, but does not discover  
until it is about to set up the message that it cannot send it.

One scenario is that the server does not know that its certificate(s) does  
not specify OCSP until it tries to get it. One could call that bad design,  
but it could also be based on reducing code complexity (e.g., don't  
involve the certificate parsing code when I am building the server hello)

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/