Subject: [Gen-art] Gen-art last call review of draft-ietf-tls-multiple-cert-status-extension-04

From: Elwyn Davies <[email-masked]>
Date: Fri, 22 Mar 2013 00:41:48 +0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-tls-multiple-cert-status-extension-04.txt
Reviewer: Elwyn Davies
Review Date: 22 March 2013
IETF LC End Date: 29 March 2013
IESG Telechat date: (if known) -

Summary: Almost ready for IESG - one possible minor issue relating to 
the alleged criterion for ordering CertificateStatusRequestItems plus a 
number of nits that are mainly missing cross references and notes for 
clarity about updates of RFC 6066 items.

Major issues:
None

Minor issues:
s2.2:
>     The list of CertificateStatusRequestItem entries MUST be in order of
>     preference.
Having thought a bit about this, I cannot identify what the preference 
criterion is - this may be because I don't understand the problem, but I 
think you need to explain what the criterion is if there really is one.  
If there *is* a criterion, it must be clear whether the order is most 
preferred first or least preferred first. Since I don't know what the 
criterion is, I can't tell if there are any security implications from 
the ordering: no chance of downgrade attacks?

Nits/editorial comments:
s2:
The presentation format used should be referenced back to s4 of RFC 5246.

s2.1:
A reference to s1.1 of RFC 6066 where extension_type is defined is 
needed, and it should be made more clear that this an expansion of the 
existing type.

s2.2:
A reference to s7.4.1.4 of RFC 5246 where extension_data is defined is 
needed.

s2.2, page 4:
Might be good to be more explicit that the definition of 
CertificateStatusRequest is an extension of the definition in RFC 6066.  
Also the definition of OSCPStatusRequest duplicates the one in RFC 6066 
and should be noted as such.  It would also be more appropriate if it 
came before CertificateStatusRequest as it is used in 
CertificateStatusRequest.

s2.2, para 4 on page 5:
>     In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560  <http://tools.ietf.org/html/rfc2560>] is
>     unclear about its encoding; for clarification,.....
This probably needs to be flagged up in the IANA considerations so that 
an additional reference is added to the registry.
ALSO I subsequently noted that this same caveat is already in RFC 6066.  
Consider referring to the caveat there rather than duplicating it.

s2.2, para 5 on page 5:
s/A server that receive a client hello/A server that receives a client 
hello/

s2.2, page 5/6:
Might be good to be more explicit that the definition of 
CertificateStatus is an extension of the definition in RFC 6066.
Also the definition of OSCPResponse duplicates the one in RFC 6066 and 
should be noted as such.  It would also be more appropriate if it came 
before CertificateStatus as it is used in CertificateStatus.

s2.2, page 6:
The definition of OCSPResponseList should come before the redefinition 
of CertificateStatus as it is used in CertificateStatus.

s2.2, para 2 after structure definitions on page 6:
A reference to s7.4.2 of RFC 5246 for the Certificate list would be helpful.

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 23 Mar 2013 11:56:08 +0100

Hi,

Thanks for the review

> the ordering: no chance of downgrade attacks?

The list is ordered by the client, based on whatever criteria its
developer uses. These criteria can be based on objective evaluation of
each available method, or personal opinions about them.

I have now clarified this sentence to be similar to the ciphersuite list
language in RFC 5246

New text: "The list of CertificateStatusRequestItem entries MUST be in
order of the client's preference (favorite choice first)."

The server could still ignore that ordering when it picks the method to
use (for the ones it knows). For example if there is only one OCSP
response available for a chain, e.g because there is no intermediate or
the intermediate does not have an OCSP responder assigned,  then it would
be overkill to use the multiple OCSP variant, so the single response
version would be used instead.

> The presentation format used should be referenced back to s4 of RFC 5246.

Would probably be an idea. The reason it was left out is that RFC 6066
does not include such a reference.

I have now added a section 1.2 saying "This document defines protocol
structures using the same conventions and presentation language as defined
in Section 4 of [RFC 5246]"

> needed, and it should be made more clear that this an expansion of the

Added a reference

> A reference to s7.4.1.4 of RFC 5246 where extension_data is defined is

Added a reference

> CertificateStatusRequest.

Added a reference

> Consider referring to the caveat there rather than duplicating it.

This language is, as you mention, a copy of the RFC 6066 note about this
problem.

I think it is better to duplicate it, since it is so small. A longer and
more complex section would probably have been referenced, but adding such
references for small informational text would IMO make the document less
readable.

> s/A server that receive a client hello/A server that receives a client

done

> before CertificateStatus as it is used in CertificateStatus.

Added references "(originally defined by [RFC6066])".

> of CertificateStatus as it is used in CertificateStatus.

There is actually, as far as I am able to tell, no established convention
in the TLS document family that the usage in a containing structure have
to be before the precise definition; e.g. see for example sections 7.4.2
and 7.4.3 in RFC 5246.

In fact, as a C/C++ programmer I very much prefer to have the included
structure defined before the usage (although that is not done in this
document).

> A reference to s7.4.2 of RFC 5246 for the Certificate list would be  

Inserted "[RFC5246] (Section 7.4.3)" before "Certificate" (I thought there
would be too many parentheses by adding it afterwards)

-- 
Sincerely,
Yngve N. Pettersen

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

---

From: Elwyn Davies <[email-masked]>
Date: Sat, 23 Mar 2013 12:48:30 +0000

Hi.

> Thanks for the review
.. and thanks for the rapid response!

Couple of comments in line below.. I've snipped the agreed stuff.

Regards,
Elwyn
> use (for the ones it knows). 

OK that explains the criterion.  However, as in the cipher suite list in
RFC 5246, using a requirements MUST is inappropriate as it is not a
testable protocol condition.  I think what you are trying to get over is
that the *server* SHOULD work from beginning to end of the list giving
higher priority to items earlier in the list so that the client's
desires are satisfied as far as possible.

> For example if there is only one OCSP

Does this need some words then?

> > Nits/editorial comments:
<<snip>>
> references for small informational text would IMO make the document less

Fair enough - and I realize this isn't an IANA matter.  However, if this
is an issue for RFC 2560, shouldn't somebody file an erratum?  I
couldn't see anything about this in the current set of errata.

<<snip>>

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 23 Mar 2013 14:12:48 +0100

Hi,

> couldn't see anything about this in the current set of errata.

It is actually corrected in RFC2560bis  
<http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/> (sec.  
4.4.1), currently in PKIX WG Last Call.

At present my document is not linked to that document (since that would  
create a dependency that could block publication), although that might  
happen if they are actually published around the same time (as Sean is  
thinking of). Even if it is linked, I think this information should be  
left in the document, to be on the safe side.

As background, to my knowledge no mass market client actually send this  
OCSP extension, particularly in the stapling request; I am also not aware  
that any general OCSP responder support it, although I have heard mentions  
that high security (military) responders do. (Opera did send it in the  
early OCSP implementations when querying OCSP responders directly). Except  
for special usage scenarios (like the military one) using this extension  
and expecting it to be used in the response will lead to extra load on  
both the server and the responder, as well as extra overhead, removing  
much of the benefit of the stapling system.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Elwyn Davies <[email-masked]>
Date: Sat, 23 Mar 2013 15:54:26 +0000

> 4.4.1), currently in PKIX WG Last Call.
Ah.. That's fine... I don't follow pkix! 
> left in the document, to be on the safe side.
That's also fine.  It doesn't need the hassle but obviously updating the
ref later would help if it doesn't delay things
> much of the benefit of the stapling system.
Such is life!
Thanks for the explanation.
/Elwyn

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 23 Mar 2013 18:47:22 +0100

Hi again

> desires are satisfied as far as possible.

The main information to get across is that the listed sequence is the  
client's order of preference, so that an implementor does not assume the  
ordering has no meaning.

Whether that require a MUST can probably be debated.

As mentioned, a server could decide to use its own ordering, but this  
would be at the cost of increasing complexity. A simple implementation  
would be to follow the client's ordering, and I think the preference for  
this is implied by stating that the ordering is the client's preference.

I have now tweaked the text a little further, removing the MUST:

"The items in the list of CertificateStatusRequestItem entries are in  
order of the client's preference (favorite choice first)."

Note: I am not quite satisfied with the wording here, and I think the  
grammar is not quite as it should be, and I am open to tweak suggestions.

> Does this need some words then?

At present I don't think so.

That kind of selection is an optimization that is available to the server  
implementor, if he wants to save a few bytes.

That option is implicit in that both modes are available in the  
definition. The server can pick whichever method works best.

Additionally, if/when other revocation methods, e.g. such as SCVP, are  
added, it is conceivable that the CA might limit the options available to  
the server, by not providing OCSP at all, which means that a client that  
prefer multiple ocsp before SCVP would still get SCVP because OCSP is not  
available.

-- 
Sincerely,
Yngve N. Pettersen