[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02
From: "Yngve N. Pettersen" <yngve () spec-work ! net>
Date: 2013-01-01 19:54:23
Message-ID: op.wp8z8xm23dfyax () acorna ! invalid ! invalid
[Download RAW message or body]
Hi,
[Please note: New email address]
The suggestion look mostly OK to me, but I think it should recommend
always sending bad_certificate_status_response when the client decides to
abort the handshake due to the received OCSP response (e.g. by treating
"unknown" or "unauthorized" as fatal errors); I am not sure Joe's text
said that clearly.
A suggestion for a small update:
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 other unacceptable responses (as determined by client policy),
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 abort 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 might 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 with the handshake, but it would be inappropriate for the client
to disclose a username and password until it has fully validated the
server certificate.
On Sun, 16 Dec 2012 01:35:14 +0100, Joseph Salowey (jsalowey)
<jsalowey@cisco.com> wrote:
> 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
>
>
> On Dec 2, 2012, at 10:39 AM, Piyush Jain <piyush@ditenity.com> wrote:
>
>> Please see inline.
>>
>>> -----Original Message-----
>>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
>>> Yngve N. Pettersen (Developer Opera Software ASA)
>>> Sent: Sunday, December 02, 2012 9:04 AM
>>> To: tls@ietf.org; Nikos Mavrogiannopoulos
>>> Subject: Re: [TLS] WGLC for
>> draft-ietf-tls-multiple-cert-status-extension-02
>>>
>>> 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.
>>
>>
>> [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.
>>
>>> 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.
>>>
>> [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
>>> 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
>>> <nmav@gnutls.org> wrote:
>>>
>>>> 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-extens
>>>>> ion-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
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>> --
>>> Sincerely,
>>> Yngve N. Pettersen
>>> **********************************************************
>>> **********
>>> Senior Developer Email: yngve@opera.com
>>> Opera Software ASA http://www.opera.com/
>>> Phone: +47 96 90 41 51 Fax: +47 23 69 24 01
>>> **********************************************************
>>> **********
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
--
MVH,
Yngve N. Pettersen
Using Opera's mail client: http://www.opera.com/mail/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic