Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 02 Dec 2012 09:28:10 +0100

On 11/16/2012 06:08 PM, Joseph Salowey (jsalowey) wrote:

> This is a working group last call for draft-ietf-tls-multiple-cert-status-extension-02 on "The TLS Multiple Certificate Status Request Extension".  The draft is available here:
> 
> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-02
> Please send you comments to the TLS list  by December 17, 2012.   

I pretty much repeat the point originally made in:
http://www.ietf.org/mail-archive/web/tls/current/msg08973.html

The text:
   "Clients requesting an OCSP response and receiving one or more OCSP
   responses in a "CertificateStatus" message MUST check the OCSP
   response(s) and abort the handshake, if the response is a revoked
   status or is otherwise not satisfactory with a
   bad_certificate_status_response(113) alert.  This alert is always
   fatal."

is very strict and IMO not applicable in this document since this
document is not about a verification profile. What if a client decides
to proceed with the handshake even if the status is revoked? Or if an
implementation when it detects junk in this extension (due to a server
misconfiguration) decides to ignore it instead of aborting.

Should that make the clients non-conformant to the
multiple-cert-status-extension?

regards,
Nikos

---

From: "Piyush Jain" <[email-masked]>
Date: Sun, 2 Dec 2012 08:35:18 -0800

>    bad_certificate_status_response(113) alert.  This alert is always

 It's probably okay to abort the handshake for 'revoked' status but not for
'unsatisfactory' response, given that unsatisfactory could mean a lot of
things. One simple example is that OCSP response is signed using a
hashing/signature example that the client does not understand. If the client
is trying to obtain the certificate status directly, it can use RFC 6277 to
resolve this or, in the worst case fall back to CRLs to obtain the
revocation status.

This brings up another interesting question. The request_extensions field of
OCSPStatusRequest is marked as opaque in the current proposal. Given that,
he proposed extension is useful only if the TLS server caches the status
response from OCSP servers, IMO the TLS server should at least try to honor
PreferredSignatureAlgorithms request extension defined in 6277. 

-Piyush

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sun, 02 Dec 2012 18:03:34 +0100

Hi,

As I said last time you raised this issue, it is the same requirement as  
RFC 6066 sets <http://tools.ietf.org/html/rfc6066#section-8> for the  
original Certificate Status extension. I also think it is proper to have  
such a requirement, because it defines how the data should be handled and  
acted upon, and collects the information in a single document, so it is  
not necessary to chase one document after another to discover all the  
proper actions.

This requirement clearly indicates that *if* a client request this  
extension, then it MUST verify the result, and act on the result in a  
secure fashion. That is, only proceed if the response is "good", and abort  
in other cases. (If a client does not want to process and act on the  
information, it can avoid doing so by not sending the extension support  
indication to the server; sending the extension is a declaration that the  
client accepts and will act upon the returned information in a fashion  
that protects the user.)

The server have the option to not forward a response in case it is bad, in  
which case the client should fetch the response on its own. If the  
forwarded response is bad, then the client have to act on it, and  
terminate the connection.

A client that proceeds despite seeing either bad data or a revoked status  
are IMO not conformant, and will IMO also have a security vulnerability.

As this language was not just acceptable to the Working Group for RFC  
6066, but the WG actually approved that 6066 added the alert message  
requirement, which was not present in either RFC 4366 or RFC 3546, my  
opinion is that the WG have so far clearly and repeatedly stated its  
opinion on this matter, and I therefore plan to leave this text in.

On Sun, 02 Dec 2012 09:28:10 +0100, Nikos Mavrogiannopoulos  
<[email-masked]> wrote:

>> This is a working group last call for  
>> draft-ietf-tls-multiple-cert-status-extension-02 on "The TLS Multiple  
>> Certificate Status Request Extension".  The draft is available here:
>>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sun, 02 Dec 2012 18:10:35 +0100

On Sun, 02 Dec 2012 18:03:34 +0100, Yngve N. Pettersen (Developer Opera  

> RFC 6066 sets <http://tools.ietf.org/html/rfc6066#section-8> for the

Just a slight correction: My draft adds a specific requirement for  
"revoked", mostly to be on the safe side, along with the adaption to  
multiple response. Otherwise the text is as in RFC6066.

> such a requirement, because it defines how the data should be handled  
> and acted upon, and collects the information in a single document, so it  
> is not necessary to chase one document after another to discover all the  
> proper actions.
>
> secure fashion. That is, only proceed if the response is "good", and  
> abort in other cases. (If a client does not want to process and act on  
> the information, it can avoid doing so by not sending the extension  
> support indication to the server; sending the extension is a declaration  
> that the client accepts and will act upon the returned information in a  
> fashion that protects the user.)
>
> The server have the option to not forward a response in case it is bad,  
> in which case the client should fetch the response on its own. If the  
> A client that proceeds despite seeing either bad data or a revoked  
> status are IMO not conformant, and will IMO also have a security  
> vulnerability.
>
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 02 Dec 2012 19:34:13 +0100

On 12/02/2012 06:03 PM, Yngve N. Pettersen (Developer Opera Software

> is not necessary to chase one document after another to discover all the

Hello Yngve,
 It is my opinion that, the capital MUST in the original RFC6066 may
have been wrong also. However, in the RFC6066 case the text is very
vague. E.g. it says: Clients ... MUST check the OCSP response and abort
the handshake if the response is not satisfactory, ...

So the satisfactory could mean anything depending of the context. In
your draft you clarify that, by mentioning that the client is obliged to
terminate the connection if the certificate is revoked. The
clarification is good as a suggestion to the implementer, but it has the
side-effect (due to the original MUST) that a client will not to be
conformant with  draft-ietf-tls-multiple-cert-status-extension-02 if it
decides to go on despite the revoked status.

The TLS rfcs mandate no verification policies and even when they discuss
verification is informally (see F.1.1 in TLS 1.2) and there are no MUSTs
or SHOULDs. Also in 7.4.6 the text explicitly mentions that a server
that receives an unacceptable certificate by the client acts at its
discretion. I think this should be followed in this draft as well.

So while I think you addition is good, and could even be better to
elaborate further, e.g. by specifying what to do when the status request
is unsatisfactory[*], I don't think it should be a MUST (nor any other
RFC2119 keywords). It could be just "must".

[*]. As you explain in the open issue note.

regards,
Nikos

---

From: "Piyush Jain" <[email-masked]>
Date: Sun, 2 Dec 2012 10:39:47 -0800

Please see inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yngve N. Pettersen (Developer Opera Software ASA)
> Sent: Sunday, December 02, 2012 9:04 AM
> To: [email-masked]; Nikos Mavrogiannopoulos
> Subject: Re: [TLS] WGLC for
draft-ietf-tls-multiple-cert-status-extension-02
> As I said last time you raised this issue, it is the same requirement as
RFC 6066
> sets <http://tools.ietf.org/html/rfc6066#section-8> for the original
> Certificate Status extension. I also think it is proper to have such a
> requirement, because it defines how the data should be handled and acted
> upon, and collects the information in a single document, so it is not
necessary
> to chase one document after another to discover all the proper actions.

[Piyush] 6066 does not cover multiple cert status extension.
Multiple-cert-status extension is being proposed to address the limitations
of original certificate status request actions.  So  any improvements in how
the response should be handled can be part of the new documents
> This requirement clearly indicates that *if* a client request this
extension,
> then it MUST verify the result, and act on the result in a secure fashion.
That
> is, only proceed if the response is "good", and abort in other cases. (If
a client
> does not want to process and act on the information, it can avoid doing so
by
> not sending the extension support indication to the server; sending the
> extension is a declaration that the client accepts and will act upon the
> returned information in a fashion that protects the user.)
> 
[Piyush] I agree that if the response indicates that certificate is bad, the
handshake should be terminated. However, absence of 'good' does not imply
'bad' in OCSP. Good and revoked are the only authoritative responses in
OCSP. Any other response is non-authoritative. This implies that for
responses other than good or revoked, client should try to find the status
using other means before considering the certificate good or bad. Here are
the other possible scenarios.
- Unknown response. Not interesting because TLs servers should be smart
enough to not include unknown response. However, I'm surprised that this
draft does not explicitly states that tls server must not include unknown
OCSP response (or unsigned OCSP responses) in status-request message.
- Response not understood by client, typically because it is signed using a
hashing/signing algorithm that client did not understand. It does not make
sense for the client to abort the handshake in such cases. The client should
try to obtain the certificate status using other means.

> which case the client should fetch the response on its own. If the
forwarded
> response is bad, then the client have to act on it, and terminate the
> connection.
> 
[Piyush] Good point. I think the draft should call it out explicitly and
prohibit the server to send any response that it thinks is not
authoritative.
> A client that proceeds despite seeing either bad data or a revoked status
are
> IMO not conformant, and will IMO also have a security vulnerability.
> 
[Piyush] Agree if the status is revoked. Bad data is too generic. Please
look at the scenario mentioned above.
> As this language was not just acceptable to the Working Group for RFC
6066,
> but the WG actually approved that 6066 added the alert message
opinion
> on this matter, and I therefore plan to leave this text in.
> 

> >> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extens
> >> ion-02 Please send you comments to the TLS list  by December 17,
> >> 2012.
> >

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 16 Dec 2012 00:35:14 +0000

I don't see a valid case for the client to continue if the response is valid and indicates revoked.   Since unknown is a valid OCSP response I don't think we should forbid it.  In cases where the response is inconclusive it is up to the client to determine how to proceed.   The client may choose to allow the connection to complete in the case that it believes it will have the opportunity to check the validity of the certificate through another means.  Such an example would be in the case of EAP-TLS where the client may use a different method of revocation check when it has network access.  However the client MUST NOT engage in activities with the server that require trust in the validity of the certificate until the certificate has been validated.  For example, a client MUST not disclose username and password information until it has fully validated the validity of the server certificate.  

Here is an attempt at some suggested text: 

  "Clients requesting an OCSP response and receiving one or more OCSP
  responses in a "CertificateStatus" message MUST check the OCSP
  response(s) and abort the handshake if the response is a revoked
  status with a bad_certificate_status_response(113) alert.  This alert is always
  fatal.  If the response is inconclusive then the client MAY decide to allow the 
  connection if it believes it will have the opportunity to check the validity
   of the certificate through another means.   The client MUST about the 
  connection if it needs to engage in activities  that require trust in the server 
  and the server certificate has not been sufficiently  validated.  An 
  example of where the client may wish to continue is with EAP-TLS
  where the client can use another mechanism to check the status of a 
  certificate once it obtains network access.  In this case the client may 
  continue withe handshake, but it would be inappropriate for the client 
  to disclose a username and password until 
  it has fully validated the validity of the server certificate."

Thanks,

Joe

---

From: "Piyush Jain" <[email-masked]>
Date: Sun, 16 Dec 2012 12:12:36 -0800

Thanks Joe,

Agree with most. 
However, I do think it makes sense to recommend that server does not include
an unknown response. 
Presence of an unknown response does not provide any benefit to the client
and bloats the message. I signed "I don't know' is no better than no
response at all.

-Piyush

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: Saturday, December 15, 2012 4:35 PM
> To: Piyush Jain
> Cc: Yngve N. Pettersen (Developer Opera Software ASA); <[email-masked]>;
> Nikos Mavrogiannopoulos
> 
> I don't see a valid case for the client to continue if the response is
valid and
> indicates revoked.   Since unknown is a valid OCSP response I don't think
we
> should forbid it.  In cases where the response is inconclusive it is up to
the
> client to determine how to proceed.   The client may choose to allow the
> connection to complete in the case that it believes it will have the
> opportunity to check the validity of the certificate through another
means.
> Such an example would be in the case of EAP-TLS where the client may use a
> different method of revocation check when it has network access.  However
> the client MUST NOT engage in activities with the server that require
trust in
> the validity of the certificate until the certificate has been validated.
For
> example, a client MUST not disclose username and password information
> until it has fully validated the validity of the server certificate.
> 
> >> Certificate Status extension. I also think it is proper to have such
> >> a requirement, because it defines how the data should be handled and
> >> acted upon, and collects the information in a single document, so it
> >> is not
> > necessary
> > Multiple-cert-status extension is being proposed to address the
> > limitations of original certificate status request actions.  So  any
> > improvements in how the response should be handled can be part of the
> > new documents
> >>
> >> not sending the extension support indication to the server; sending
> >> the extension is a declaration that the client accepts and will act
> >> upon the returned information in a fashion that protects the user.)
> >>
> > [Piyush] I agree that if the response indicates that certificate is
> > bad, the handshake should be terminated. However, absence of 'good'
> > does not imply 'bad' in OCSP. Good and revoked are the only
> > authoritative responses in OCSP. Any other response is
> > non-authoritative. This implies that for responses other than good or
> > revoked, client should try to find the status using other means before
> > considering the certificate good or bad. Here are the other possible
> scenarios.
> > - Unknown response. Not interesting because TLs servers should be
> > smart enough to not include unknown response. However, I'm surprised
> > that this draft does not explicitly states that tls server must not
> > include unknown OCSP response (or unsigned OCSP responses) in status-
> request message.
> > - Response not understood by client, typically because it is signed
> > using a hashing/signing algorithm that client did not understand. It
> > does not make sense for the client to abort the handshake in such
> > cases. The client should try to obtain the certificate status using
other
> means.
> >
> >> The server have the option to not forward a response in case it is
> >> bad, in which case the client should fetch the response on its own.
> >> If the
> > forwarded
> > [Piyush] Good point. I think the draft should call it out explicitly
> > and prohibit the server to send any response that it thinks is not
> > authoritative.
> >> status
> > [Piyush] Agree if the status is revoked. Bad data is too generic.
> > Please look at the scenario mentioned above.
> >>
> >>>> draft-ietf-tls-multiple-cert-status-extension-02 on "The TLS
> >>>> Multiple Certificate Status Request Extension".  The draft is
available
> here:
> >>> document is not about a verification profile. What if a client
> >>> decides to proceed with the handshake even if the status is revoked?
> >>> Or if an implementation when it detects junk in this extension (due
> >>> to a server

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 17 Dec 2012 01:47:04 +0000

> and bloats the message. I signed "I don't know' is no better than no

[Joe] To me, it seemed a simpler implementation just to always  include whatever response you have.  I believe the client will always have to deal with the case that it may receive an unknown response.  Having the client implementation explicitly think about what they will do with the unknown response would hopefully lead to more robust implementations.

---

From: "Piyush Jain" <[email-masked]>
Date: Sun, 16 Dec 2012 21:16:59 -0800

Fair point. Clients should be able to deal with all kind of responses.
I guess we can leave it to the server implementations to figure out if they
see any value in attaching an unknown response.

I have heard a few knowledgeable people argue that a signed unknown response
is more valuable than no response even though I could never find a useful
scenario where that would be true :).

-Piyush

> Sent: Sunday, December 16, 2012 5:47 PM
> To: Piyush Jain
> > However, I do think it makes sense to recommend that server does not
> > include an unknown response.
> > Presence of an unknown response does not provide any benefit to the
> > client and bloats the message. I signed "I don't know' is no better
> > than no response at all.
> >
> 
> [Joe] To me, it seemed a simpler implementation just to always  include
> whatever response you have.  I believe the client will always have to deal
> with the case that it may receive an unknown response.  Having the client
> implementation explicitly think about what they will do with the unknown
> response would hopefully lead to more robust implementations.
> 
> 
> 
> > -Piyush
> >
> >> Cc: Yngve N. Pettersen (Developer Opera Software ASA);
> >> <[email-masked]>; Nikos Mavrogiannopoulos
> >> Such an example would be in the case of EAP-TLS where the client may
> >> use a different method of revocation check when it has network
> >> access.  However the client MUST NOT engage in activities with the
> >> server that require
> > trust in
> >> status with a bad_certificate_status_response(113) alert.  This alert
> >> is always  fatal.  If the response is inconclusive then the client
> >> MAY decide to
> > allow the
> >>  connection if it needs to engage in activities  that require trust
> >> in
> > the server
> >> certificate once it obtains network access.  In this case the client
> >> may  continue withe handshake, but it would be inappropriate for the
> >> client  to disclose a username and password until  it has fully
> >> validated the validity of the server certificate."
> >>
> >>
> >> Thanks,
> >>
> >> Joe
> >>
> >>
> >>>> From: [email-masked] [mailto:[email-masked]] On Behalf
> >>>> Of Yngve N. Pettersen (Developer Opera Software ASA)
> >>>> sets <http://tools.ietf.org/html/rfc6066#section-8> for the
> >>>> original Certificate Status extension. I also think it is proper to
> >>>> have such a requirement, because it defines how the data should be
> >>>> handled and acted upon, and collects the information in a single
> >>>> document, so it is not
> >>> necessary
> >>> improvements in how the response should be handled can be part of
> >>> the new documents
> >>>>
> >>> non-authoritative. This implies that for responses other than good
> >>> or revoked, client should try to find the status using other means
> >>> before considering the certificate good or bad. Here are the other
> >>> possible
> >> scenarios.
> >>>> response is bad, then the client have to act on it, and terminate
> >>>> the connection.
> >>>>
> >>>> requirement, which was not present in either RFC 4366 or RFC 3546,
> >>>> my opinion is that the WG have so far clearly and repeatedly stated
> >>>> its
> >>> opinion
> >>>>>> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-ex
> >>>>>> te
> >>>>>> ns
> >>>>>  "Clients requesting an OCSP response and receiving one or more
> >>>>> OCSP  responses in a "CertificateStatus" message MUST check the
> >>>>> OCSP
> >>>>> Or if an implementation when it detects junk in this extension
> >>>>> (due to a server