Subject: [TLS] cipher suites for protecting client credentials

From: Mohamad Badra <[email-masked]>
Date: Tue, 13 Mar 2012 22:10:58 +0100

Dear all,

I have taken an initial crack at a document that defines a set of cipher
suites to add client credential protection to TLS:

http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-ciphersuite-identity-protection-00.txt

Looking forward for your comments, best regards
Badra

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 14 Mar 2012 14:46:21 +0200

Hi Badra, 

I looked at your document but I do not quite understand what you are
trying to accomplish. 

When you say that you want to "protect" the client credentials what do
you mean?

When a client authenticates to the server based on public key
cryptography it sends a certificate (among other things). 

Could you elaborate?

Ciao

Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Mohamad Badra
Sent: Tuesday, March 13, 2012 11:11 PM
To: [email-masked]
Subject: [TLS] cipher suites for protecting client credentials

Dear all,

http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-ciphers
uite-identity-protection-00.txt

Badra

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Mar 2012 15:22:04 +0200

Hi Hannes

There was some talk about things like this in Taipei. His ciphersuites move the client Certificate to after the CCS, so a passive eavesdropper does not get the client identity.

Yoav

On Mar 14, 2012, at 2:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

Hi Badra,

I looked at your document but I do not quite understand what you are trying to accomplish.

When you say that you want to “protect” the client credentials what do you mean?
When a client authenticates to the server based on public key cryptography it sends a certificate (among other things).

Could you elaborate?

Ciao
Hannes

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Mohamad Badra
Sent: Tuesday, March 13, 2012 11:11 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [TLS] cipher suites for protecting client credentials

Dear all,

I have taken an initial crack at a document that defines a set of cipher suites to add client credential protection to TLS:

Scanned by Check Point Total Security Gateway.

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 14 Mar 2012 15:37:37 +0200

Hi Yoav, 

I was in Taipei at the meeting and I even do not recall this. I guess it
should be explained in the draft. 

I also have a proposal for the terminology:

http://tools.ietf.org/html/draft-iab-privacy-terminology-01

Ciao
Hannes

From: ext Yoav Nir [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2012 3:22 PM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: ext Mohamad Badra; [email-masked]
Subject: Re: [TLS] cipher suites for protecting client credentials

Hi Hannes

There was some talk about things like this in Taipei. His ciphersuites
move the client Certificate to after the CCS, so a passive eavesdropper
does not get the client identity.

Yoav

Hi Badra,

Could you elaborate?

Ciao

Hannes

Dear all,

Badra

[email-masked]

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 14 Mar 2012 14:39:48 +0100

Hi Hannes

Yoav answered your question.

"protect" the client credentials is to avoid sending the client certificate
in cleartext during TLS Handshake

Best regards
Badra

On Wed, Mar 14, 2012 at 1:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) <
[email-masked]> wrote:

> Hi Badra, ****
> ** **
> trying to accomplish. ****
>
> ** **
>
> When you say that you want to “protect” the client credentials what do you
> mean?****
>
> When a client authenticates to the server based on public key cryptography
> it sends a certificate (among other things). ****
>
> ** **
>
> Could you elaborate?****
>
> ** **
>
> Ciao****
>
> Hannes****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *ext
> Mohamad Badra
> *Sent:* Tuesday, March 13, 2012 11:11 PM
> *To:* [email-masked]
> *Subject:* [TLS] cipher suites for protecting client credentials****
>
> ** **
>
> Dear all,****
>
> ** **
>
> suites to add client credential protection to TLS:****
>
> ** **
>
>
> ****
> ** **
> Looking forward for your comments, best regards****
>
> Badra****
>

---

From: Tom Ritter <[email-masked]>
Date: Wed, 14 Mar 2012 09:41:49 -0400

> http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-ciphersuite-identity-protection-00.txt

What's the advantage of using ciphersuites instead of an extension?
This was already proposed in the form of an extension:
http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts - using
ciphersuites seems much more messy.  You're pidgeon-holed into using
the specific ciphersuites that are defined in the draft - no DHE, no
AES-GCM, etc etc.  Plus there's the massive ballooning of ciphersuites
defined.  I think (not sure) that it could inflate the ClientHello
moreso than an extension also.

I like the idea though.

-tom

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 14 Mar 2012 15:47:17 +0200

Hi Mohamad, 

One aspect we noticed when the IAB did privacy reviews of existing IETF specifications was that most people did not describe their threat model and the terminology was often confusing as well. 

You may also want to take a look at our most recent version of the privacy guidelines document: 
http://tools.ietf.org/html/draft-iab-privacy-considerations-02

I believe you mostly care eavesdroppers along the path between the TLS client and the TLS server when using client-side authentication within TLS. Correct?

We defined the term "Identity Confidentiality" in http://tools.ietf.org/html/draft-iab-privacy-terminology-01#section-3.3
and it covers this case. 

I do not believe you provide any other privacy properties in your proposal (which is OK). 

Ciao
Hannes

From: ext Mohamad Badra [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2012 3:40 PM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [email-masked]
Subject: Re: [TLS] cipher suites for protecting client credentials

Hi Hannes

"protect" the client credentials is to avoid sending the client certificate in cleartext during TLS Handshake

Best regards
Badra

On Wed, Mar 14, 2012 at 1:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) <[email-masked]> wrote:
Hi Badra, 

When you say that you want to "protect" the client credentials what do you mean?
When a client authenticates to the server based on public key cryptography it sends a certificate (among other things). 
 
Could you elaborate?
 
Ciao
Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Mohamad Badra
Sent: Tuesday, March 13, 2012 11:11 PM
To: [email-masked]
Subject: [TLS] cipher suites for protecting client credentials
 
Dear all,

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 14 Mar 2012 14:59:30 +0100

Hi Tom

> What's the advantage of using ciphersuites instead of an extension?

Martin Rex already discussed that on
http://www.ietf.org/mail-archive/web/tls/current/msg08288.html

Another reason is that extension-based solution This solution may
sufferfrom interoperability issues related to TLS Extensions, TLS 1.0
and TLS 1.1
implementations

using
> moreso than an extension also.
Last November, I posted another a way to signal the change in the messages'
order by defining a single SCSV. Please
see draft-badra-tls-identity-protection-01

You cannot enable DHE and ECDHE and have certificate confidentiality if you
send CCS before the client certificate. However, I posted a document during
2009 that supports both DHE and ECDHE key exchange algorithms. This
document [1] had been approved by IESG but never published as RFC
(RFC-Editor denied its publication recently)
[1] draft-hajjeh-tls-identity-protection-09

Best regards
Badra

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 14 Mar 2012 15:04:02 +0100

Hi Hannes,

You may also want to take a look at our most recent version of the privacy
> guidelines document:
> I believe you mostly care eavesdroppers along the path between the TLS
> client and the TLS server when using client-side authentication within TLS.
> Correct?
>
>
Correct!

> We defined the term "Identity Confidentiality" in
> http://tools.ietf.org/html/draft-iab-privacy-terminology-01#section-3.3
> and it covers this case.
>

 I read Section 3.3 and it describes the problem addressed by the draft.

I do not believe you provide any other privacy properties in your proposal
> (which is OK).
True.

> Hannes
Best regards,
Badra

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Wed, 14 Mar 2012 15:20:15 +0100

> sufferfrom interoperability issues related to TLS Extensions, TLS 1.0

1: Servers will have to be updated in any case to handle this new method,  
that means that they will (or should) not have interoperability issues  
with extensions (if for no other reason that they should also get the  
Renego issue fixed at the same time, if they have not already done so)

2: Modern clients (browsers in particualr) already send TLS extensions (a  
selection of SNI, Renego Extension, Certificate Status, Session tickets,  
ECC, etc.) and already have policies for handling version and extension  
intolerant servers.

IOW, adding a new extension will not change the current situation in any  
way.

According to my scans, currently 1.58% of servers are extension  
intolerant, down from 1.75% 6 months ago.

IMO, if this is implemented, it should be implemented using an extension,  
not cipher suites.

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

---

From: "Peirce, Ken" <[email-masked]>
Date: Wed, 14 Mar 2012 10:28:59 -0400

Hello Badra et alia.,

I want to be certain I understand the draft.

1. The Server authenticates itself to the Client.

2. The Client does *not* provide either a temporary or certificate based
public key for the establishment of the TLS session.

3. The Client issues the CCS to signal encryption will be employed from
that point on. At this point the Client has the all of the material
required to generate the session's encryption key.

4. The Client now presents an encrypted certificate to the Server. This
provides the Server with the material it requires to generate the
session's encryption key.

5. The Server can now issue its CCS to signal its future use of
encryption.

I believe that the above is technically correct/feasible.

One widely accepted layering principle is to decouple service

authorization from client authentication on access.  We therefore

recommend that authorization decisions be performed and communicated

at the application layer after the TLS handshake has been completed.

1. I like the idea of protecting the identity of the Client. 

2. I like the idea of having the application perform the Client
certificate validation. It can result in the simplification of the TLS
API/interface.  

3. The only potential downsides I see are practical. 

1. Pushing the authentication up the stack from its present location
decentralizes the authentication process. This will likely increase the
latency for session establishment that in turn may affect the
scalability of the solutions that employ this method.  

2. The linking software between the Transport and Application layers
will need to be fuzz tested to avoid introducing vulnerabilities.

Clever idea.

Thanks,

Ken

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoav Nir
Sent: Wednesday, March 14, 2012 9:22 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [email-masked]
Subject: Re: [TLS] cipher suites for protecting client credentials

Hi Hannes

Yoav

Hi Badra,

Could you elaborate?

Ciao

Hannes

Dear all,

Badra

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 14 Mar 2012 22:05:56 +0100

> IMO, if this is implemented, it should be implemented using an extension,

draft-badra-tls-identity-protection-01 specifies a single cipher suite. I
don't see the advantages of defining an extension over using a single
cipher suite. Would you elaborate please?

BTW, what was the percent of server that are extension intolerant in Feb
2010?

Best regards,
Badra

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 14 Mar 2012 22:12:33 +0100

Hello Ken,

On Wed, Mar 14, 2012 at 3:28 PM, Peirce, Ken <[email-masked]> wrote:

>
>
> 1. The Server authenticates itself to the Client.****
>
> 2. The Client does **not** provide either a temporary or certificate
> based public key for the establishment of the TLS session.****
>
> required to generate the session’s encryption key.****
>
> provides the Server with the material it requires to generate the session’s
> encryption key.****
>
> 5. The Server can now issue its CCS to signal its future use of encryption.
> ****
>
> **
>

True (in 4. The client sends its certificate)

**
> Clever idea.****
> Thanks,****

Thank you
Best regards
Badra

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 14 Mar 2012 23:27:05 +0100

> cipher suite. Would you elaborate please?

The purpose of the TLS Extensions mechanism is to signal support for  
non-standard functionality (such as modifying the handshake sequence), or  
provide information to the server (such as SNI).

Signaling cipher suite values have only been used *once* in TLS: In the  
Renego patch RFC. That was only in order to work around the issue of being  
able to signal Rengo Indication support when the client could not use  
extensions at all. This was necessary in such a case to prevent a version  
rollback attack (which is currently successful in almost all clients) from  
disabling the Renego patch.

Given that the contemplated functionality is to modify the handshake  
sequence so that the certificate and certificate verify messages are sent  
after encryption starts, what is needed is an indication of support for  
non-standard functionality, which can be best signaled using an Extension.  
Overloading a cipher suite value for such an indication is IMO a bad idea  
(renego was, and should continue to be, a special case). Any server that  
is likely to implement the proposed functionality will almost certainly  
already support TLS Extensions, so there is no real need to consider the  
possibility that the server does not support them.

And the rather small difference in size between the minimum extension (4  
bytes) and the SCSV (2 bytes) is IMO not reason enough to go for the SCSV  
option.

Additionally, the server would have to signal back to the client that it  
is willing to accept the modified sequence. That means that an extension  
will have to be defined for this purpose in any case, so why complicate  
things?

Of course, there is another way to accomplish the same goal: Define a new  
version of TLS.

> BTW, what was the percent of server that are extension intolerant in Feb

I don't have reliable numbers before August 2011, due to some result  
processing bugs (I have not investigated if they can be reconstructed  
based on recorded results). In early August 2011 (the first after all the  
problem were resolved) the result for Extension intolerance in the TLS  
1.0-TLS 1.2 range (which is what is reported above) range was 2.03%.

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 15 Mar 2012 00:54:50 +0100

On Wed, Mar 14, 2012 at 11:27 PM, Yngve N. Pettersen (Developer Opera
Software ASA)
> disabling the Renego patch.

NO, the SCSV is mainly specified because of compatibilty reasons (see
RFC5746 Section 3.3):

   "Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require
   implementations to ignore data following the ClientHello (i.e.,
   extensions) if they do not understand it.  However, some SSLv3 and
   TLS 1.0 implementations incorrectly fail the handshake in such a
   case.  This means that clients that offer the "renegotiation_info"
   extension may encounter handshake failures.  In order to enhance
   compatibility with such servers, this document defines a second
   signaling mechanism via a special Signaling Cipher Suite Value (SCSV)
   ..."

BTW, why nowadays it is not true that "client could not use extensions at
all"?

> will have to be defined for this purpose in any case, so why complicate

For the same compatibility issue described above, and it does not
complicate things!

Any server that is likely to implement the proposed functionality will
> almost certainly already support TLS Extensions, so there is no real need
> to consider the possibility that the server does not support them.

It is true that the server needs to support that extension, but we still
need to ensure compatibility.
BTW, the draft-badra-tls-identity-protection-02 defines an extension to be
sent by the server when a SCSV is received in ClientHello (please see
http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-identity-protection-02.txt
).

In draft-badra-tls-ciphersuite-identity-protection-00, you don't need to
define extensions, and you ensure compatibility with servers that ignore
data following the ClientHello.

Best regards,
Badra

---

From: Marsh Ray <[email-masked]>
Date: Wed, 14 Mar 2012 20:02:21 -0500

On 03/14/2012 06:54 PM, Mohamad Badra wrote:
>     Signaling cipher suite values have only been used *once* in TLS: In
>     the Renego patch RFC. That was only in order to work around the
>     issue of being able to signal Rengo Indication support when the
>     client could not use extensions at all. This was necessary in such a
>     case to prevent a version rollback attack (which is currently
>     successful in almost all clients) from disabling the Renego patch.
>

But these two reasons are closely related and from the perspective of a 
client implementer like Yngve they are nearly the same: Yngve's client 
code tries the handshake first with TLS extensions. If that fails, it 
may try the handshake again without any extensions.

So this "compatibility" would represent a downgrade attack against RI 
without the SCSV, even when the legitimate client and server both 
supported extensions.

There was a *lot* of discussion about this back when it was decided. The 
one thing I think everyone agrees on is that SCSV was a bit of an 
emergency hack made necessary only because of the presence of 
extension-intolerant servers.

- Marsh

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Thu, 15 Mar 2012 02:53:20 +0100

> BTW, why nowadays it is not true that "client could not use extensions at

One of the version rollback modes used by clients is SSL v3-only, without  
extensions. In fact, I think until MS started to support TLS 1.2, it was  
the only fallback mode used by clients other than Opera. Opera have, until  
now, also had a TLS 1.0 without extension mode, and at one time also had a  
TLS 1.1 w/o extension mode.

Those are the situations under which the Renego SCSV would be needed. And  
the reason it is needed is that an attacker could trick the client into  
falling back to such a mode, and if not for the SCSV being included in the  
handshake, the attacker could successfully trick the server and client  
into completing a connection that could be attacked using the renego  
attack. That attack scenario could have been prevented by requiring  
clients to always send extension, but due to the compatibility issues  
clients had to fall back to configurations that did not send extensions,  
which is why the SCSV became necessary. A renego patched server should be  
both version and extension tolerant, so the most likely reason for being  
intolerant is an attack (of renego patched servers 0.035% are version  
intolerant in TLS 1.0-TLS 1.2 range, 0.12% extension intolerant, about  
half of which does not tolerate specific extension)

AFAICT such a critical security problem does not exist in this case. The  
server is the one requesting credentials, and if it does not receive other  
indications, it can trigger renegotiation of the connection to perform  
that while protecting the privacy of the user (which do require the Renego  
patch in order to be done safely).

> For the same compatibility issue described above, and it does not

It does complicate things.

A supporting server would have to have instructions for looking for the  
signal in two places, the extensions and the cipher suites, and would need  
to know what to do if both were there (0.97% of renego patched servers  
does not tolerate a client hello that send _both_ the extension and the  
SCSV). All of this increases the likelihood (towards certainty) that  
somebody will introduce a interoperability issue, which in turn will mean  
that clients will have to create even more complex fallback procedures, at  
a time when I, for one, want to get rid of them. In the case of only  
having the SCSV, not an extension, with a signal back in a extension would  
look as funny as the renego SCSV (and that one has _barely_ tolerable  
reasons for being defined that way).

A server that does support the proposed change would need to support  
Extensions, thus the SCSV is not needed. (unless a variant using fully  
specified cipher suites as proposed earlier was used, which is not a good  
idea for many reasons, one being scalability)

A server that does not support the proposed change and tolerates  
extensions would ignore the extension, and the SCSV is not needed, since  
the server does not understand it.

A server that does not support the proposed change, and also does not  
tolerate extensions, would ignore the SCSV since it does not understand  
it, and all modern clients would anyway have to do a version/extension  
fallback for these servers because the server would not tolerate the  
extensions they sent, in any case. Thus the SCSV is not needed for this  
scenario either.

> need to ensure compatibility.

Which extension supporting clients already do (for the present time) by  
falling back to configurations that does not use extensions. But if all  
the supporting servers understand extensions there is no need to signal  
the client's support of that functionality to servers that will never  
support the functionality.

> http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-identity-protection-02.txt

Which, as mentioned earlier, means that it can be sent as an extension and  
not an SCSV. The server that supports that proposal would (or should)  
understand extensions in the client hello.

> data following the ClientHello.

Those servers would very likely not support the functionality at all, and  
if they ignore extensions that probably mean they should be upgraded to  
support the renego patch, which means that they would understand  
extensions, too.

Servers that are updated with this kind of functionality will require  
quite a bit of changes to their internal logic, so making sure they  
understand extensions (which they need to do for other purposes, such as  
Renego) would probably not increase the complexity all that much,  
particularly when support for several of the defined extensions is  
desirable on their own merits. I would also guess that such a server would  
probably be upgraded to support TLS 1.2 at the same time (particularly in  
light of the BEAST vulnerability), which means it have to support  
extensions.

As an example, the minimal OCSP Certificate Status extension could,  
conceivably, have been implemented as an SCSV signal, and support signaled  
back by the extension. However, servers that did not support that  
functionality would not understand the SCSV, whether or not they  
understood/tolerated extensions, and those that did support the  
functionality would (or should) naturally understand extensions, thus an  
SCSV is unnecessary, and an unneeded complication.

IMO, doing tricks with cipher suites to control the handshake sequence is  
a waste of resources, except when fixing critical security vulnerabilities  
(and, even then, only as a last resort). The scenario it is targeted at  
(an extension ignoring/intolerant server that supports an advanced  
modification of the handshake) is very likely such an extreme cornercase  
that it would probably only be realized as a proof of concept, not used in  
production systems, and I see no reason to encourage such a cornercase to  
be developed.

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Mar 2012 03:38:27 +0100 (MET)

> > cipher suite. Would you elaborate please?

If at all, this scheme ought to be implemented with a TLS extension,
using an SCSV ciphersuite value for downgrade protection and for use
by clients that do not support TLS extensions at all and programmatic
clients that do not have an application level re-connect fallback
and therefore do never send any TLS extensions.

> provide information to the server (such as SNI).

So far the theory goes.

But then, the TLS working group failed badly to get the extensibility
pushed out for the SSLv3 protocol spec into the installed base when
the complete lack of extensibility in the original SSLv3 protocol
was noticed and complained on:

  http://lists.w3.org/Archives/Public/ietf-tls/msg02599.html

> will have to be defined for this purpose in any case, so why complicate  

Not using the TLS extension in the ClientHello (but instead always the SCSV)
will actually save the most (in terms of implementation complexity and
test cases).

> extensions at all.

Nope, that rationale was rejected back then and you still reject it now,
although there are still implementations left that do not support
TLS extensions, because they would not be allowed to send it in ClientHello
anyway.

>
> This was necessary in such a case to prevent a version  

*That* was the real reason why it was allowed in by the high priests,
to protect the "cutting edge TLS clients" that are not only willing to
try TLS extensions, but also have fallbacks in place.

> non-standard functionality, which can be best signaled using an Extension.  

Maybe in 10 years from now, when the last extensions intolerant servers
have gone.

> intolerant, down from 1.75% 6 months ago.

That is a global average for public servers on the internet and not
really meaningful.  Typical clients connect only to a very small
number of servers, typically less than 100 (ignoring the advertising
and statcounter junk that one probably would _not_ mind to loose).

For those user that actually want to use the services of such users,
the issue may be very relevant.

> Overloading a cipher suite value for such an indication is IMO a bad idea  

It is not a bad idea, it is merely an alterative approach to implement a
1-bit TLS ClientHello extension  in a fully backwards compatible fashion.

>
> (renego was, and should continue to be, a special case).

As long as clients can be forced to downgrade, that special case
continues to exist.o

Maybe when *ALL* browser vendors have removed the options (and capabilities)
to use SSLv3 or to send extension-less TLS ClientHellos, then we can
seriously claim that sending TLS extensions is safe.  But until then,
the use of an SCSV for an extension like client identity protection
is quite sensible.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Mar 2012 20:49:20 -0700

> the use of an SCSV for an extension like client identity protection

I'm not really interested in relitigating the SCSV-vs-extension issue, but
in the specific case of client identity protection, I don't see how SCSV
provides rollback protection. The reason that the SCSV is (generally)
less susceptible to rollback than extensions is that an attacker can
simulate being un-extension-capable and and force the client into
trying a non-extension handshake without breaking the Finished,
whereas there aren't SCSV-intolerant servers, so the Finished
detects SCSV removal.

However, unless I'm missing something, that doesn't apply here because
the client sends the Certificate before the Finished, so the Finished
is too late to detect tampering. The attacker can just simulate not
having the extension, wait for the client Certificate, and then RST the
connection instead of sending the Finished.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Mar 2012 05:20:25 +0100 (MET)

> whereas there aren't SCSV-intolerant servers, so the Finished

Correct.  If both, client and server offer a feature that is considered
worth having, the protocol should be resilient to attackers that want
the connection to be established without that feature.

> connection instead of sending the Finished.

Unless I'm missing something: The key exchange is authenticated with the
server credential/certificate, and the client certificate will be
encrypted under ephemeral keys derived from that authenticated key exchange.

So an attacker can only get at the credential when he can either fully
impersonate the server or entice the client to connect (and send that
credential) to an entirely different server.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Mar 2012 21:26:17 -0700

> the connection to be established without that feature.

Sure. But I don't believe this feature can be offered in that
way if the client is prepared not to negotiate that feature.

> credential) to an entirely different server.

Yes, that's how it's *supposed* to work, but if the client is willing to
do unencrypted certificates, then the attacker can just force him back
to that:

Here's how this works:
C->S: ClientHello + EncryptedCert indicator
A->C: ServerHello (no indicator)
C->A: Certificate, ClientKeyExchange, CertificateVerify
A->C: RST

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Wed, 14 Mar 2012 23:29:16 -0500

> connection instead of sending the Finished.

The ID says
> Consequently, static Diffie-Hellman SHOULD NOT be used with this document.

But really it's incompatible with all forms of Diffie-Hellman. Which 
would seem to be a big step backwards compared to the current 
capabilities of TLS.

Current TLS clients and servers can agree to pass client credentials 
using authenticated encryption to cover a renegotiation handshake. This 
method is not perfect, but it is widely used today. There should be some 
discussion in the ID of exactly what is being gained by the new method.

Regardless, are there any examples of clients today that would refuse to 
provide the client credentials if asked by an attacker on a 
(not-yet-authenticated) initial handshake?

If not, perhaps a better first step would be standardizing a method (say 
via a field in the x509 client cert itself) to inform the client TLS 
stack that the cert MUST NOT be transmitted except as properly encrypted 
to an authorized server.

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Mar 2012 21:31:30 -0700

On Wed, Mar 14, 2012 at 9:29 PM, Marsh Ray <[email-masked]> wrote:
> But really it's incompatible with all forms of Diffie-Hellman. Which would
> seem to be a big step backwards compared to the current capabilities of TLS.

Hmm... I don't see why. Can you explain?

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Wed, 14 Mar 2012 23:34:31 -0500

> Hmm... I don't see why. Can you explain?

IIRC, ephemeral Diffie-Hellman isn't actually authenticated until the 
Finished message.

So the MitM can supply his own DH parameters right?

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Mar 2012 06:01:23 +0100 (MET)

> Hmm... I don't see why. Can you explain?

True -- so we would need a new X.509v3 cert attribute in the Server
certificate to signal back to the client in a fashion that the
attacker can not subvert.

(we discussed this previously on this list, I just failed to remember...)

https://www.ietf.org/mail-archive/web/tls/current/msg08297.html

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Mar 2012 22:06:49 -0700

> attacker can not subvert.

Correct, but of course at that point downgrade attack in the TLS handshake
itself is no longer a concern for this feature.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Mar 2012 01:04:24 -0500

Instead of this (taken from the I-D):

            Client                           Server

            ClientHello       -------->
                                             ServerHello
                                             Certificate
                                             CertificateRequest
                              <--------      ServerHelloDone
            ClientKeyExchange
            ChangeCipherSpec
            Certificate
            CertificateVerify
            Finished          -------->
                                             ChangeCipherSpec
                              <--------      Finished
            Application Data  <------->      Application Data

I propose this:

      Client                                               Server

      ClientHello                  -------->
      (With an extension saying "I can
       send user cert/verify immediately
       before my first app data".
       The server's hello must confirm.)
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      ClientKeyExchange
      ChangeCipherSpec
      Finished                     -------->

                                               [ChangeCipherSpec]
                                   <--------             Finished
      Certificate
      CertificateVerify
      Application Data             -------->
                                   <--------             Finished
      Application Data             <------->     Application Data

This seems a lot easier to analyze, and it's still an optimization
over renego (though not as good as the one you propose).

Also, billing this as optimized renego seems a lot better to me.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 15 Mar 2012 09:08:53 +0200

Or even this:
     Client                                               Server

     ClientHello                  -------->

                                              [ChangeCipherSpec]
                                  <--------             Finished
     Application Data             -------->
                                  <--------   CertificateRequest
     Certificate
     CertificateVerify            -------->
     Application Data             <------->     Application Data

In this case the first Application Data sent by the client carries something like "GET /LoginWithCerts.html", which would trigger renego otherwise. Or if the entire website requires client certificates, the CertificateRequest could just follow the Finished.

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 15 Mar 2012 15:24:54 +0100

Eric Rescorla wrote:

> so the Finished is too late to detect tampering

> Instead of this (taken from the I-D):

TLS clients need an indication from the server that is authenticated by the
server and cannot be stripped from the handshake. IMO, we don't need major
changes to the messages order or to send/receive application data before
sending/receiving the Finished messages.

What about the following:

            Client                           Server

            ClientHello       -------->
                                             ServerHello
                                             Certificate
                                             CertificateRequest
                              <--------      ServerHelloDone
            ClientKeyExchange
            ChangeCipherSpec  -------->
                                             ChangeCipherSpec
                              <--------      Finished

            Certificate
            CertificateVerify

            Finished          ------->

The client will abort the handshake if the identity protection indication
is not considered by the server when computing the verify_data.

(BTW, it is not legal to send the ServerKeyExchange message because the
current approach is limited to RSA key exchange method).

Best regards,
Badra

On Thu, Mar 15, 2012 at 8:08 AM, Yoav Nir <[email-masked]> wrote:

> In this case the first Application Data sent by the client carries
> something like "GET /LoginWithCerts.html", which would trigger renego
> otherwise. Or if the entire website requires client certificates, the
> CertificateRequest could just follow the Finished.
>

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Mar 2012 01:49:35 +0100 (MET)

Yoav Nir wrote:
> otherwise. Or if the entire website requires client certificates,
> the CertificateRequest could just follow the Finished.

I find this approach appealing.  The stuff that is signed by
CertificateVerify here is slightly different from what is signed
during the regular handshake, though.

We still have the Finished Message around (tls channel bindings).
While binding the finished message is weaker that the handshake
message hash that goes into the original CertificateVerify,
it is probably OK (excessive truncation of the finished message
in TLSv1.2 is a pity).

Doing it in this fashion would get rid of the problem of the channel
binding or the tls exporters changing when the server requests the
client certificate not in the initial handshake.

It amounts to an "optimized renegotiation" for the sole purpose of
requesting a client certificate.  Existing Apps that are exposed to
the flow of the TLS handshake tokens (like apps sitting on top
of transportless APIs, such as Microsoft's SSPI for schannel,
might be surprised by a "renegotiation" that completes in 1 round-trip,
so this is a feature that should be employed by the TLS stack only
by request of the caller.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Mar 2012 20:03:37 -0500

Marsh's point remains.

We're talking about how to authenticate with privacy protection in
fewer round-trips.  That's nice.  But how does the client know whether
it can reveal its identity (cert) to a given server, and if so, which
ID (since the client can have many).

There are several methods by which the client could know:

 - out of band
 - policy information delivered with cert when using CSRs
 - policy information embedded in the cert
 - online infrastructure
 - user interaction

and probably more.  This does need addressing, otherwise if an active
attacker with a valid cert can cause the client to reveal its ID
-which is bad a priori given the point of renego and this extension-
then we've not achieved the goal of protecting the client's ID.

Nico
--

---

From: Tom Ritter <[email-masked]>
Date: Fri, 16 Mar 2012 09:16:05 +0100

On 16 March 2012 02:03, Nico Williams <[email-masked]> wrote:

> an active attacker with a valid cert
>

We started the discussion with a proposal designed to protect against a
passive eavesdropper, then moved to an active attacker willing to break the
handshake, then an active attacker who can fully impersonate the server.
I'm not saying this progression is bad, but obviously it makes things way
more complicated. If the attacker can fully impersonate the server and/or
the client is willing to send their client cert to the server - I don't
know if there's much protocol wise that can be done.

A thought I had, probably dinged by my lack of PKI consulting, is if the
"Always send the client cert confidentially" flag wasn't on the server cert
but instead the client cert.  The client cert would be unusable without
talking to a server who supported the mode - but in all deployments I've
seen of Client Certs the user and server already have a trust relationship,
and the user follows the server's instructions to obtain a client cert.  If
client certs expire in a reasonable timeline, after the server is upgraded,
all employees will roll onto the newer certs after a period of time.  And
the user will never be tricked into sending the certificate unencrypted -
if an active adversary removes the indicator for encrypted client certs,
the client fails.  The big drawback is that a client cert now becomes
unusuable on the 'broad' internet, which has not been upgraded and cannot
accept encrypted client certs.

-tom

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 16 Mar 2012 10:59:56 +0200

Just a thought that came to my mind: How often is client authentication
via certificates used in TLS in the real world? 

If you think about all the Web use cases then there authentication
happens at the application layer. 

If you think about the network access authentication use cases then
folks are more focused on tunneled methods (instead of plain EAP-TLS). 

For enterprise uses cases where client certificates are used there you
often have the WebSSO solution in place and there the scenario is likely
different as well.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Tom Ritter
Sent: Friday, March 16, 2012 10:16 AM
To: [email-masked]
Subject: Re: [TLS] cipher suites for protecting client credentials

We started the discussion with a proposal designed to protect against a
passive eavesdropper, then moved to an active attacker willing to break
the handshake, then an active attacker who can fully impersonate the
server.  I'm not saying this progression is bad, but obviously it makes
things way more complicated. If the attacker can fully impersonate the
server and/or the client is willing to send their client cert to the
server - I don't know if there's much protocol wise that can be done.

A thought I had, probably dinged by my lack of PKI consulting, is if the
"Always send the client cert confidentially" flag wasn't on the server
cert but instead the client cert.  The client cert would be unusable
without talking to a server who supported the mode - but in all
deployments I've seen of Client Certs the user and server already have a
trust relationship, and the user follows the server's instructions to
obtain a client cert.  If client certs expire in a reasonable timeline,
after the server is upgraded, all employees will roll onto the newer
certs after a period of time.  And the user will never be tricked into
sending the certificate unencrypted - if an active adversary removes the
indicator for encrypted client certs, the client fails.  The big
drawback is that a client cert now becomes unusuable on the 'broad'
internet, which has not been upgraded and cannot accept encrypted client
certs.

-tom

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 16 Mar 2012 13:09:06 +0100

> attacker can not subvert.

I believe there is a better alternative that could be done at the TLS
level; what if the server sends its Finished (see diagram below) before
sending the client's certificate and computes the verify_data in case it
supports the SCSV, as follows:

      verify_data
         PRF(master_secret, finished_label, Hash(handshake_messages +
{0xXX, 0xXX}))

            [0..verify_data_length-1];

where + mean concatenation and {0xXX, 0xXX} is the SCSV's code point.

The client MUST verify that the contents are correct to continue the
Handshake. Otherwise, it MUST abort the handshake.

This protects clients against tampering attacks and allows them to receive an
indication from the server that is authenticated by the server and cannot
be stripped from the handshake.

            Client                           Server

            ClientHello       -------->
                                             ServerHello
                                             Certificate
                                             CertificateRequest

            Certificate
            CertificateVerify

            Finished          ------->

Comments?
Best regards,
Badra

---

From: Nico Williams <[email-masked]>
Date: Fri, 16 Mar 2012 08:27:03 -0500

On Fri, Mar 16, 2012 at 3:16 AM, Tom Ritter <[email-masked]> wrote:
> the client is willing to send their client cert to the server - I don't know
> if there's much protocol wise that can be done.

The TLS threat model assumes active attackers, else we wouldn't bother
with server certificates.  This is why things are complicated already
:)

It follows that we if we care about confidentiality of client
certificates then we should assume active attackers.  This means that
the authorization function for deciding when to present a(which)
client certificate cannot depend merely on the server's having a valid
certificate.

> but instead the client cert.  The client cert would be unusable without

This is one of the things Marsh suggested.  I realize that in my post
I didn't clarify which cert might carry authorization information for
this.  But I think it's clear that it's much easier to use such
information when it's in the client's cert.

> and the user follows the server's instructions to obtain a client cert.  If

In those cases you can have out-of-band authz-data.  Out of band does
not scale to Internet scale, but:

> the user will never be tricked into sending the certificate unencrypted - if
> an active adversary removes the indicator for encrypted client certs, the
> client fails.  The big drawback is that a client cert now becomes unusuable
> on the 'broad' internet, which has not been upgraded and cannot accept
> encrypted client certs.

Client certs are already pretty much not used on the Internet.

Nico
--

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 16 Mar 2012 16:22:53 +0100

On Fri, Mar 16, 2012 at 2:27 PM, Nico Williams <[email-masked]>wrote:

> the
> know

Still not clear to me how in your opinion does TLS protect clients from
active attackers with valid certificate?

> certificates then we should assume active attackers.

Active attackers are considered into account in the draft.

This means that
> client certificate cannot depend merely on the server's having a valid

It depends on the server's having a valid certificate and on an
authenticated indication (that the server supports identity protection)
sent to the client.

Best regards,
Badra

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Mar 2012 08:42:24 -0700

On Mar 16, 2012, at 1:59 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> Just a thought that came to my mind: How often is client authentication via certificates used in TLS in the real world?

Often. It is just not use often on the web for typical commerce.

> If you think about all the Web use cases then there authentication happens at the application layer.

Completely false. There are plenty of use cases where the server would not want to even proceed with the underlying protocol if it didn't know ahead of time that the client was able to authenticate.

> If you think about the network access authentication use cases then folks are more focused on tunneled methods (instead of plain EAP-TLS).

TLS is used for many things other than network access. :-)

> For enterprise uses cases where client certificates are used there you often have the WebSSO solution in place and there the scenario is likely different as well.

And there are plenty of places where WebSSO is completely inappropriate.

If you are suggesting "TLS is really only for web access", your argument holds. TLS is designed, and actively used, for much more than that.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Mar 2012 08:47:49 -0700

> with server certificates.  This is why things are complicated already

Indeed.

> certificates then we should assume active attackers.  

Yes.

> client certificate cannot depend merely on the server's having a valid

Not necessarily. It is perfectly fine for us to say "we care about protecting the identity in the client certificate only from passive attackers if protecting from active attackers adds significant complexity". It is also perfectly fine for us to say "we care about protecting the identity in the client certificate in all cases". However, the latter should not be assumed, given the already complex nature of TLS.

If the WG goes forward with "protect the client cert" work, I would want to see the best proposal for protecting just against passive attackers and the best proposal for protecting against active attackers before I decide what is to complicated. I suspect the latter will be beyond what I would want to deploy, and would be happy to be wrong about that.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Fri, 16 Mar 2012 11:15:20 -0500

> Not necessarily. It is perfectly fine for us to say "we care about protecting the identity in the client certificate only from passive attackers if protecting from active attackers adds significant…

You could argue that this authorization problem is entirely external
to TLS.  The client application has to make the decision.  So... go
talk to the PKIX WG if you need anything from PKIX (e.g., cert
extensions for carrying CA-issued policy information for the app to
interpret).

I'm fine with that.  But the fact that this authorization has to
happen (even if it's just "reveal my ID to any server with a valid
cert") needs to be documented in the security considerations of TLS.
I don't see anything about this in an admittedly cursory scan of
RFC5246.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 16 Mar 2012 11:16:10 -0500

> active attackers with valid certificate?

Think of redirection/misdirection, typo squatting, ...

Nico
--

---

From: Florian Weimer <[email-masked]>
Date: Fri, 16 Mar 2012 16:23:01 +0000

> via certificates used in TLS in the real world? 

Various folks have written middleware on top of TLS and rely on client
certificates for authentication.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 16 Mar 2012 12:43:36 -0400

> active attackers with valid certificate?

As a point of clarification: are you talking about an active attacker 
with a copy of the server's valid certificate *and* a copy of the 
server's secret key?

Or are you just asking about an active attacker with a copy of the valid 
certificate but *without* the corresponding secret key?

In the former case, i'm not sure what TLS as a protocol can possibly do 
to protect the client from anything (including disclosure of identity).

In the latter case, we need to consider an active attacker willing to 
cause a handshake failure in order to learn the identity of the client.

	--dkg

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 16 Mar 2012 19:58:36 +0100

> Think of redirection/misdirection, typo squatting, ...

I cannot see anything in the Security Considerations of RFC5246, is there
any RFC that discussed these issues?

Daniel Kahn Gillmor <[email-masked]> wrote:

>
> As a point of clarification: are you talking about an active attacker with
> a copy of the server's valid certificate *and* a copy of the server's
> secret key?
>
>
Yes

> In the former case, i'm not sure what TLS as a protocol can possibly do to
> protect the client from anything (including disclosure of identity).
>

Indeed

In the latter case, we need to consider an active attacker willing to cause
> a handshake failure in order to learn the identity of the client.

The cattacker will never learn the client identity, even if the handshake
fails

Best regards
Badra

---

From: Nico Williams <[email-masked]>
Date: Fri, 16 Mar 2012 15:40:11 -0500

On Fri, Mar 16, 2012 at 1:58 PM, Mohamad Badra <[email-masked]> wrote:
> On Fri, Mar 16, 2012 at 5:16 PM, Nico
> Williams <[email-masked]> wrote:
>>

RFC5246 doesn't discuss anything regarding how the client should
decide whether to use a cert (or which) with any given server.  It's
not surprising that it wouldn't discuss any issues regarding
redirection either.

So if a client is willing to show its cert to any server with a valid
cert... then an active attacker need only cause a client to talk to a
server that the attacker controls that has a valid cert.  On the web
this is child's play.  You could typo squat on some domain and setup
http to redirect to https and then have the server request client
certificates.  Or, simpler, if you're on the path then you can just...
respond to any http request with a redirect to your attack host... if
users get a dialog about the redirection you can count on enough
clicking through anyways.

The point is: if you're going to have a mechanism for protecting the
confidentiality of the user cert then you kinda have to do something
to prevent the above.  In an IMAP client, say, (or LDAP, or SUBMIT)
this attack is not realistic, but in a browser it seems quite
realistic to me.

Nico
--

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 16 Mar 2012 22:17:38 +0100

> this attack is not realistic, but in a browser it seems quite

Will it be our only concern to care about "client identity protection" when
our server is totally broken by an active attacker?

Concerns related to the client identity protection becomes really
ridiculous when the above thing happens.

What will be the solution to protect clients (no certificates) from such an
attacker or at least to discover it by these clients?

Best regards,
Badra

---

From: Nico Williams <[email-masked]>
Date: Fri, 16 Mar 2012 16:35:54 -0500

> our server is totally broken by an active attacker?

The attacker has not compromised any servers in this scenario:

0) user enters http://somesite.example
1) attacker responds with a redirect to https://domain-owned-by-the-attacker
   To make this better the attacker's domain can be a typosquat on
somesite.example
2) attacker's server requests a client cert
3) client/user picks a cert
4) client sends a cert
5) attacker learns the client's cert

Nico
-

---

From: Nico Williams <[email-masked]>
Date: Fri, 16 Mar 2012 17:11:12 -0500

On Fri, Mar 16, 2012 at 5:06 PM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
> On 03/16/2012 10:35 PM, Nico Williams wrote:
> This is pretty extreme scenario. If the client decided to send his

Extreme?  It's less extreme than BEAST, say, except that there
probably isn't that much value in learning client identities, so it's
probably not a very likely attack.

> certificate to a malicious server, how would you prevent that?

Well, first, I'm not actually proposing that there be a solution.  I'm
pointing out that for some use cases (web browsers) there's not that
much use to a client identity confidentiality protection scheme that
doesn't say anything at all about how the client decides whether a[n
authenticated] server is to be allowed to see the client's
certificate.

Second, there are possible ways to protect the client from this
redirect/misdirect attack.  I'm not sure which of those are likely to
be workable in practice, but it's worth considering.  Paul Hoffman
points out that such solutions are probably outside the purview of the
TLS WG but I'm not so sure.  We may want to figure out a) whether we
care (but I think it's silly not to care about this attack), b) where
to work on it.

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 16 Mar 2012 23:18:02 +0100

On 03/16/2012 10:35 PM, Nico Williams wrote:

>> Will it be our only concern to care about "client identity
>> protection" when our server is totally broken by an active
>> attacker?
> 
> 0) user enters http://somesite.example 1) attacker responds with a
> redirect to https://domain-owned-by-the-attacker To make this better
> the attacker's domain can be a typosquat on somesite.example 2)
> attacker's server requests a client cert 3) client/user picks a cert 
> 4) client sends a cert 5) attacker learns the client's cert

The scenarios that I think such a draft should target would be one of
the following (I don't think there are other possibilities but I might
be wrong):
1. identity protection for client against passive attackers
2. identity protection for client _and_ server against passive attackers
3. identity protection for client against passive and active attackers.
4. identity protection for client against passive and active attackers
and against passive for the server.

Currently as I understand the draft offers (1) mostly because is
targeted on web security, but for several applications where server and
client do not actually differ (p2p protocols), (2) might make more sense.

(3) and (4) look appealing to cases where the client-server relation
exists and revealing the client identity has a cost, which is not an
everyday use-case but certainly some applications could benefit from it.

regards,
Nikos

---

From: Mohamad Badra <[email-masked]>
Date: Sat, 17 Mar 2012 00:20:46 +0100

> 5) attacker learns the client's cert
The draft in its "Security Considerations" Section discusses that and makes
some recommendations that may help to avoid this attack. The application
itself can help too (maintain a blocked list, etc...).

Best regards,
Badra

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 17 Mar 2012 09:35:32 +0100

On 03/16/2012 11:11 PM, Nico Williams wrote:

> probably isn't that much value in learning client identities, so
> it's probably not a very likely attack.

I mean extreme to be handled by the low-level protocol. It looks like
an attack to be mitigated by the user interface application (e.g. by
explicitly warning the user that is sending this certificate for the
first time to this server or something similar).

> Well, first, I'm not actually proposing that there be a solution.
> I'm pointing out that for some use cases (web browsers) there's not
> that much use to a client identity confidentiality protection scheme
> that doesn't say anything at all about how the client decides whether
> a[n authenticated] server is to be allowed to see the client's 
> certificate.

Authentication is also (and mostly) depending on the upper protocols.
E.g. in SMTP client authentication might mean something very different
than HTTPS client authentication, thus it might make sense to delegate
some of the security considerations to the upper protocols. If there are
common pitfalls across protocols it might make sense to have some
general guidelines, but I don't think much can be done on the TLS layer
for the attack that you specify.

regards,
Nikos

---

From: Nico Williams <[email-masked]>
Date: Sat, 17 Mar 2012 20:14:42 -0500

So, after thinking about it more I think any authorization to see a
cert problem is well outside the scope of this WG.  Apps already have
this problem regarding username&password-over-TLS authentication
anyways.  This does rate a security considerations mention though.

Nico
--

---

From: Mohamad Badra <[email-masked]>
Date: Sun, 18 Mar 2012 10:26:09 +0400

On Sun, Mar 18, 2012 at 5:14 AM, Nico Williams <[email-masked]>wrote:

> ... I think any authorization to see a
> cert problem is well outside the scope of this WG.

TLS clients establish TLS sessions based on parameters set by the
Applications (protocol version, cipher suites, etc). I don't see any
technical reason to don't negotiate the certificate protection during the
handshake.

Looking for your technical reasons, best regards,
Badra

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 18 Mar 2012 12:42:01 -0700

> anyways.  This does rate a security considerations mention though.

Disagree that it is out of scope for the WG. I don't think there is a strong use case, given that it is pretty trivial for a client to get a cert whose identity is not actually related to the person using the cert, but others do think there is the use case so it should be dealt with. There are use cases where a server wouldn't want to finish the handshake without knowing that the client is authorized to even talk to the next protocol.

I still hate the idea of munging cipher suites for the functionality, though.

--Paul Hoffman

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 27 Mar 2012 21:59:42 +0200

Dear All,

I posted a revised version of "SCSV for TLS Client Credential Protection".
In this version, no need for any extension or for changes in the server
certificate to include an authenticated indication to the client that the
server supports identity protection. Moreover, active attacks are not
possible in the current document version.

Kindly have a look on the document and send your comments (I will present
it during tomorrow TLS session).

http://www.ietf.org/id/draft-badra-tls-identity-protection-02.txt

Best regards,
Badra

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Mar 2012 00:24:26 +0200

As far as I can tell this still has an active attack. The attacker
simply replies
to the client by aborting the handshake as shown in S 2. At this point,
the client has the option of connecting normally (and disclosing his
cert) or not connecting. This is the same downgrade issue all other
proposals have.

Moreover, the requirement :

  o  If the server does not support the client credential protection
      described here, the server MUST abort the handshake (by sending a
      fatal handshake_failure alert).

Is incompatible with existing TLS cipher suite behavior. The world is full
of servers which will ignore the SCSV. Indeed, this is why it is attractive
in other settings.

-Ekr

On Tue, Mar 27, 2012 at 9:59 PM, Mohamad Badra <[email-masked]> wrote:
> Kindly have a look on the document and send your comments (I will present it
> during tomorrow TLS session).
>

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 28 Mar 2012 01:00:36 +0200

> cert) or not connecting. This is the same downgrade issue all other

The main concern was: the client shall receive (before sending its
certificate) an authenticated indication showing the server support of the
identity protection. I think the other proposals don't provide that.

The attack you describe cannot be defended against by TLS. However, it
doesn't apply to clients that refuse to send their certificates (I agree
this is the same downgrade issue...)

> in other settings

I will replace "MUST" with "MAY".
Best regards
Badra

> Kindly have a look on the document and send your comments (I will present
it

---

From: Marsh Ray <[email-masked]>
Date: Tue, 27 Mar 2012 21:27:43 -0500

I don't support the idea of using new SCSVs as bitflags for things 
unrelated to cipher suite selection that would more properly be 
negotiated by an extension. I realize RI uses an SCSV, but it was 
clearly an exceptional case.

I also think this is not a problem that many client apps need to solve 
right now and it's not the best way to promote the usage of client certs.

However, to be fair to Mohamad's proposal ...

> cert) or not connecting. This is the same downgrade issue all other

But by this same logic, aren't TLS 1.0, 1.1, 1.2, and all current 
extensions (with the exception noted previously) also subject to this 
downgrade attack? Is this not an argument against them too?

If the downgrade you're talking about is one of browser's behavior 
(i.e., if the highest protocol level handshake fails they retry with a 
lower version on a different TCP connection) then that seems almost out 
of scope for [TLS]. What could be said in a transport layer spec that 
could help prevent application layer logic from subverting it in this way?

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Mar 2012 05:11:51 +0200

> identity protection. I think the other proposals don't provide that.

That wasn't my main concern.

> I will replace "MUST" with "MAY".

I don't see how this helps. You still need to distinguish new from old.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Mar 2012 05:14:21 +0200

On Wed, Mar 28, 2012 at 4:27 AM, Marsh Ray <[email-masked]> wrote:
>
> I don't support the idea of using new SCSVs as bitflags for things unrelated
> to cipher suite selection that would more properly be negotiated by an
> extension. I realize RI uses an SCSV, but it was clearly an exceptional
> case.
>
> I also think this is not a problem that many client apps need to solve right
> now and it's not the best way to promote the usage of client certs.
>
> But by this same logic, aren't TLS 1.0, 1.1, 1.2, and all current extensions
> (with the exception noted previously) also subject to this downgrade attack?
> Is this not an argument against them too?
>
> If the downgrade you're talking about is one of browser's behavior (i.e., if
> the highest protocol level handshake fails they retry with a lower version
> on a different TCP connection) then that seems almost out of scope for
> [TLS]. What could be said in a transport layer spec that could help prevent
> application layer logic from subverting it in this way?

This proposal does not depend on any such application logic, as the
failure happens during the initial handshake. But yes, willingness
to back off to non-extension versions of TLS does in fact represent
a downgrade threat to most extensions.

-Ekr

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 28 Mar 2012 09:30:55 +0200

> I don't see how this helps. You still need to distinguish new from old.

I don't see how other setting can achieve that. Would you elaborate please?

Best regards
Badra

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 28 Mar 2012 09:56:25 +0200

> possible in the current document version.

Hello,
 I don't see any reason to define an SCSV ciphersuite, as
compatibility with early-SSL 3.0 draft servers isn't a major concern
for such an extension.

regards,
Nikos

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 28 Mar 2012 10:39:18 +0200

Marsh Ray <[email-masked]> wrote:

> I realize RI uses an SCSV, but it was clearly an exceptional case.
> On Wed, Mar 28, 2012 at 9:56 AM, Nikos Mavrogiannopoulos <[email-masked]>wrote:
>>
>> I don't see any reason to define an SCSV ciphersuite,
>>
>

Weren't it possible to avoid using SCSV in rfc5746? What are the
requirements to justify exceptional cases there but not here?
Best regards,
Badra

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Mar 2012 11:03:23 +0200

On Mar 28, 2012, at 10:39 AM, Mohamad Badra wrote:

Marsh Ray <[email-masked]<mailto:[email-masked]>> wrote:
I realize RI uses an SCSV, but it was clearly an exceptional case.
On Wed, Mar 28, 2012 at 9:56 AM, Nikos Mavrogiannopoulos <[email-masked]<mailto:[email-masked]>> wrote:

Weren't it possible to avoid using SCSV in rfc5746?

Yes, but all browsers that have extensions also have a no-extensions fallback mode. An attacker can force a browser to the no-extensions mode, but can't force a browser to a no-SCSV mode. The WG wanted to make sure the message about RI support definitely makes it to the server, even in the presence of an attacker that can force no-extensions mode.

What are the requirements to justify exceptional cases there but not here?

Mostly, it's been two years. Browsers complain about lack of support for RI, and this has forced most websites to update. It's no longer common to have extensions disabled. I don't think browsers are quick to take away this BC feature, and maybe Yngve has statistics about how common no-extensions servers are, but they're definitely going away.

But the big differentiator I think is urgency. That was an prefix injection attack that anyone could perform against any site with the possible ability to steal real money and cause real damage. I was able to disable the security policy on a development firewall by injecting into an administrator session. (the vulnerability was fixed in time for release). A document went from draft-00 to RFC in three months. This is not business as usual for the IETF. The attack you are trying to mitigate doesn't have the same level of ubiquity and urgency, so I don't think it warrants such a deviation from the rules.

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Mar 2012 14:16:41 +0200

> requirements to justify exceptional cases there but not here?

The SCSV in RFC 5746 was required to avoid downgrade attacks
by simulating faulty extension processing. However, in the case
of this draft, an SCSV does not prevent downgrade attacks, so
there is no reason not to use an extension.

-Ekr

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 28 Mar 2012 14:54:03 +0200

On Wed, Mar 28, 2012 at 5:11 AM, Eric Rescorla <[email-masked]>
> I don't see how this helps. You still need to distinguish new from old.

The Finished received from the server will allow client to distinguish new
from old.

Best regards
Badra

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 28 Mar 2012 15:46:11 +0200

> there is no reason not to use an extension.

The first reason is extracted from your document [1]:

"An extension is not
   suitable as extension-intolerance is one form of incompatibility"

Best regards,

Badra

[1] http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt

---

From: Marsh Ray <[email-masked]>
Date: Wed, 28 Mar 2012 11:23:09 -0500

> Weren't it possible to avoid using SCSV in rfc5746?

It would definitely have slowed deployment of the security fix.

> What are the

Approximately half the world's webservers were vulnerable to a 
man-in-the-middle attack, sometimes quite severe.

I invite you to review the full discussion in the list archives starting 
about here:
http://www.ietf.org/mail-archive/web/tls/current/msg03928.html

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Mar 2012 22:07:59 +0200

> man-in-the-middle attack, sometimes quite severe.

Half? Which half wasn't?

Sure, the amount of damage an attacker could do varied: the firewall that I could power down or disable the security policy from would count as a lot of damage, plus any case where money could be stolen, while servers where the attack was not exploitable (because maybe they used randomized ephemeral paths) would count as little damage, but where there actual servers where you could not inject a prefix?

Yoav

---

From: Marsh Ray <[email-masked]>
Date: Wed, 28 Mar 2012 15:20:50 -0500

On 03/28/2012 03:07 PM, Yoav Nir wrote:
> Sure, the amount of damage an attacker could do varied: the firewall
> that I could power down or disable the security policy from would
> count as a lot of damage, plus any case where money could be stolen,
> while servers where the attack was not exploitable (because maybe
> they used randomized ephemeral paths) would count as little damage,
> but where there actual servers where you could not inject a prefix?

MS IIS tended to not be vulnerable much of the time because it didn't 
accept client-initiated renegotiation. But it was still vulnerable when 
configured with client certs or certain other checkboxes were set.

There are probably still other devices around where renegotiation was 
simply not implemented. A lot of https hosts serve nothing but static 
content to the public anyway and would likely not be 'vulnerable' in the 
strict sense.

So in my head I combined IIS's less-than-half market share with a guess 
about a smaller percentage of other devices and web apps that were (by 
accident) not effectively vulnerable to come up with the ballpark figure 
'half'.

We could certainly come up with a better number, but why would we need it?

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Mar 2012 22:28:34 +0200

> We could certainly come up with a better number, but why would we need it?

OK. Didn't know that about IIS. I did find that some servers implemented with an old Java library didn't support renegotiation at all, but IIS is a surprise.