Subject: Re: [OAUTH-WG] security considerations for draft-ietf-oauth-mtls-12

From: Brian Campbell <[email-masked]>
Date: Thu, 1 Nov 2018 08:37:11 -0600

To be honest, I thought that was a relatively well known aspect of TLS 1.2
(and prior) and a noted difference of the new features in TLS 1.3. Also,
I'd note that we're well past WGCL for this document. But, with that said,
I suppose adding some privacy considerations text on the subject is
worthwhile. Would you propose some text for the WG to consider, John-Mark?
Bearing in mind that the implications of a certificate presented by, and
representing, an OAuth client are somewhat different than for an end-user
doing client cert authentication.

On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney <[email-masked]>
wrote:

> I would suggest that the security considerations section of
> draft-ietf-oauth-mtls-12 be expanded to include the privacy
> implications of using this on versions of TLS before 1.3.  On all
> versions of TLS before 1.3, the client cert is not encrypted and can
> be used by third parties to monitor and track users.  I recently
> posted a blog entry about this:
> https://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user.html
>
> Thanks.
>
> John-Mark Gurney
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Neil Madden <[email-masked]>
Date: Thu, 1 Nov 2018 14:55:22 +0000

I believe the standard approach to this is to only prompt for a client certificate in a renegotiation handshake rather than in the initial handshake. Renegotiations are encrypted under the existing TLS session.

— Neil

> On 1 Nov 2018, at 14:37, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> To be honest, I thought that was a relatively well known aspect of TLS 1.2 (and prior) and a noted difference of the new features in TLS 1.3. Also, I'd note that we're well past WGCL for this document. But, with that said, I suppose adding some privacy considerations text on the subject is worthwhile. Would you propose some text for the WG to consider, John-Mark? Bearing in mind that the implications of a certificate presented by, and representing, an OAuth client are somewhat different than for an end-user doing client cert authentication. 
> 
> 
> 
> 
> On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney <[email-masked]> wrote:
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 2 Nov 2018 00:21:26 +0900

Adding to it, in OAuth MTLS setting, the client cert is that of the OAuth
client, which is typically a web server and not of a natural person. The
content of the certs should be well publicized so that the natural person
and the OAuth Authorization Server involved should become aware of what
this client is, so I am not sure if there is much privacy impact in this
setting. Yes, if the client is a dedicated client for the natural person,
then there is going to be additional privacy impact, but for something like
that, we were talking of token binding instead.

On Thu, Nov 1, 2018 at 11:55 PM Neil Madden <[email-masked]>
wrote:

> I believe the standard approach to this is to only prompt for a client
> certificate in a renegotiation handshake rather than in the initial
> handshake. Renegotiations are encrypted under the existing TLS session.
>
> — Neil
>
> > On 1 Nov 2018, at 14:37, Brian Campbell <bcampbell=
> [email-masked]> wrote:
> >
> > To be honest, I thought that was a relatively well known aspect of TLS
> 1.2 (and prior) and a noted difference of the new features in TLS 1.3.
> Also, I'd note that we're well past WGCL for this document. But, with that
> said, I suppose adding some privacy considerations text on the subject is
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you._______________________________________________
> > OAuth mailing list
> > [email-masked]

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: John-Mark Gurney <[email-masked]>
Date: Thu, 1 Nov 2018 14:01:33 -0700

I do not have a good enough understanding of OAuth nor how it is used
in this draft to be able to write a proper security considerations
section about it.  You mention that the OAuth certification is
different than one for client cert authentication, but as I don't know
the standard well enough, I do not know the implications of it.

Even if the paragraph reads something like: Though client certs are
public in TLS versions 1.2 and before, they are not a privacy concern
because of x, y and z.  This would allow people who are reviewing it
to understand why it is not a privacy issue.

I only briefly reviewed this document because a coworker asked about
it, but I raised this concern because it was not mentioned in the
security considerations section.
On Thu, Nov 1, 2018 at 7:37 AM Brian Campbell
<[email-masked]> wrote:
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: John-Mark Gurney <[email-masked]>
Date: Thu, 1 Nov 2018 14:02:10 -0700

This sounds like a great thing to add.  That this draft should only be
used by clients that have many (in the hundreds, if not thousands)
"natural persons" associated with it, and if not, then you should use
X instead.

On Thu, Nov 1, 2018 at 8:21 AM Nat Sakimura <[email-masked]> wrote:
>
> Adding to it, in OAuth MTLS setting, the client cert is that of the OAuth client, which is typically a web server and not of a natural person. The content of the certs should be well publicized so that the natural person and the OAuth Authorization Server involved should become aware of what this client is, so I am not sure if there is much privacy impact in this setting. Yes, if the client is a dedicated client for the natural person, then there is going to be additional privacy impact, but for something like that, we were talking of token binding instead.
>
> On Thu, Nov 1, 2018 at 11:55 PM Neil Madden <[email-masked]> wrote:
>>

-- 
John-Mark Gurney
Principal Security Architect

---

From: Nomad On Walkabout <[email-masked]>
Date: Fri, 2 Nov 2018 23:41:28 +0000

Hi John,

I suggest you read the first few sections of the OAuth spec as it may explain better the use of terms in OAuth as they are a little different due to implementation. In this case I believe you mean "Resource Owner" as the "Client"'s certificate is not going to be a privacy issue unless as stated before the "client" is a third party entity and is likely not going to be effected by privacy concerns as I understand the in this case. Also in the first few sections of the OAuth RFC, security (and privacy) concerns are addressed stating that the latest version of SSL/TLS possible should be in use. (At the time of writing TLSv1.2 was the latest)

Cheers,
Carl
[email-masked]

On 11/1/18, 9:01 PM, "OAuth on behalf of John-Mark Gurney" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Brian Campbell <[email-masked]>
Date: Sun, 4 Nov 2018 08:13:10 +0800

That's fair. I'll see if maybe I can piece together some reasonable text
about it and/or will also try to discuss it with the WG this week in
Bangkok.

On Fri, Nov 2, 2018, 3:18 AM John-Mark Gurney <[email-masked] wrote:

> review, use, distribution or disclosure by others is strictly prohibited.
> your computer. Thank you.
>
>
>
> --
> John-Mark Gurney