Subject: Re: [drinks] TLS Client CertificateRequest?

From: "Bhatia, Vikas" <[email-masked]>
Date: Thu, 1 Mar 2012 17:58:26 -0500

Thanks Scott, The text looks good imo. I just have couple minor comments:

> The TLS handshake protocol requires certificate-based server
> authentication for all key exchange methods defined in RFC 5246 except
> DH_anon.

I would suggest to not have the above line in the text. The reason is that this is well-established in RFC 5246 and would be redundant here.

> increased if the server supports client-initiated renegotiation. This
> risk can be mitigated by disabling client-initiated renegotiation on the
> server and by ensuring that other means (such as firewall access control
> lists) are used to restrict unauthenticated client access to servers.

I am not sure if it is a requirement for all TLS servers to provide ability to turn off client initiated renegotiation, so I will just do a little modification as follows:

"This risk can be mitigated by disabling client-initiated renegotiation on the
server and/or by ensuring that other means (such as firewall access control
lists) are used to restrict unauthenticated client access to servers."

Thanks,
Vikas

> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[email-masked]]
> Sent: Tuesday, February 28, 2012 11:06 AM
> To: Bhatia, Vikas; Dean Willis
> Cc: [email-masked]
> Subject: RE: [drinks] TLS Client CertificateRequest?
>
> Proposed text for section 10.2:
>
> Sections 5 and 10.1 describe requirements for HTTPS support using TLS.
> The TLS handshake protocol requires certificate-based server
> authentication for all key exchange methods defined in RFC 5246 except
> DH_anon. Non-anonymous TLS servers can optionally request a certificate
> from a TLS client; that option is not a requirement for this protocol.
> This presents a denial of service risk in which unauthenticated clients
> can consume server CPU resources by creating TLS sessions. The risk is
> increased if the server supports client-initiated renegotiation. This
> risk can be mitigated by disabling client-initiated renegotiation on the
> server and by ensuring that other means (such as firewall access control
> lists) are used to restrict unauthenticated client access to servers.
>
> I'm open to wordsmithing.
>
> Scott
>
> > -----Original Message-----
> > From: Bhatia, Vikas [mailto:[email-masked]]
> > Sent: Tuesday, February 28, 2012 9:49 AM
> > To: Hollenbeck, Scott; Dean Willis
> > Cc: [email-masked]
> > Subject: RE: [drinks] TLS Client CertificateRequest?
> >
> > Hello Scott,
> >
> > Please provide the text that you would like to suggest pertaining to
> > this aspect of Security Considerations.
> >
> > Thanks,
> > Vikas
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> > Behalf
> > > Of Hollenbeck, Scott
> > > Sent: Wednesday, February 08, 2012 1:34 PM
> > > To: Dean Willis
> > > Cc: [email-masked]
> > > Subject: Re: [drinks] TLS Client CertificateRequest?
> > >
> > > > -----Original Message-----
> > > > From: Dean Willis [mailto:[email-masked]]
> > > > Sent: Wednesday, February 08, 2012 9:57 AM
> > > > To: Hollenbeck, Scott
> > > > Cc: [email-masked]
> > > > Subject: Re: [drinks] TLS Client CertificateRequest?
> > > >
> > > >
> > > > On Feb 1, 2012, at 12:29 PM, Hollenbeck, Scott wrote:
> > > > >
> > > > > Sections 5 and 10.1 of the protocol draft include text that
> > > describes
> > > > how these requirements will be met. I see MUSTs for HTTPS, but no
> > > > mention of a need for the server to request a certificate from a
> > > > client. Are servers required to send a TLS CertificateRequest
> > message
> > > > as part of the handshake protocol? The means is there, but it
> > doesn't
> > > > appear that the protocol includes a requirement for a server to
> > > > authenticate a client at the TLS level.
> > > >
> > > >
> > > > Nope. Basic or Digest authentication over HTTPS is considered good
> > > > enough. There's no requirement for the client to have or present a
> > > > cert.
> > >
> > > If that's the case, there's a risk of malicious clients consuming
> > > server-side resources to the point of denying service to legitimate
> > > clients. The risk should be identified in the security
> considerations
> > > section, perhaps as an additional paragraph in section 10.2. I'll
> > > suggest text if it helps.
> > >
> > > Scott
> > > _______________________________________________
> > > drinks mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/drinks
> >
> > This e-mail message is for the sole use of the intended
> recipient(s)and
> > may
> > contain confidential and privileged information of Transaction Network
> > Services.
> > Any unauthorised review, use, disclosure or distribution is
> prohibited.
> > If you
> > are not the intended recipient, please contact the sender by reply e-
> > mail and destroy all copies of the original message.

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 2 Mar 2012 12:41:13 +0000

> Sent: Thursday, March 01, 2012 5:58 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> I would suggest to not have the above line in the text. The reason is
> that this is well-established in RFC 5246 and would be redundant here.

I included it because I thought the context would be helpful, but I'm Ok with striking it.

> I am not sure if it is a requirement for all TLS servers to provide
> ability to turn off client initiated renegotiation, so I will just do a
> little modification as follows:
> 

I'm less comfortable with this change. Renegotiation is optional, but if it's supported your "and/or" change (the "or" part in particular) suggests that there may be no risk in leaving it enabled. That's not the case. A client that can renegotiate at will presents a denial of service risk.

Scott