Subject: [TLS] Avoiding first use of RI in ClientHello

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Nov 2009 14:35:02 -0800

Folks,

I wanted to try to resolve what I see as the major technical concern
people have about draft-ietf-tls-renegotiation-00, namely that the
client cannot offer secure renegotiation and be sure that it won't
cause a connection failure with a downrev (extension noncompliant)
server.

There's been a lot of discussion of whether this is a serious problem,
but it's clear that minimal risk of breaking things that currently
work (which some folks think requires not using extensions in the
initial ClientHello) is important for the timely deployment of the
fix, and with the current draft, that may require fall-back to
extension-less handshake.

It's unclear how often such fall-back logic would actually be needed,
and I do find Nelson's "tough love" approach here sort of appealing,
but it does seem to be a problem that you don't necessarily know for sure 
whether you need it or not until you've actually shipped the product 
with extensions, and possibly broken applications that currently work. 
It's especially concerning that fall-back can't be implemented reliably
inside the TLS library, e.g., if you just get a filehandle, so changes
to the app logic are required.

The rest of this message describes a simple modification [*] to
draft-ietf-tls-negotiation which I think addresses this compatibility
issue without requiring fall-back.

The idea is to use a magic cipher suite to signal that the client can
securely renegotiate (as described in
draft-mrex-tls-secure-renegotiation).  However, the server treats this
EXACTLY as if the client had offered an empty RI extension, and
responds with its own RI extension (or if it doesn't implement the
full extension framework, just adds a known byte string to the end of
the ServerHello). In other words:

Client                                          Server
------------------------------------------------------
ClientHello + TLS_RENEGO_PROTECTION_REQUEST -> 
                             <- ServerHello + Empty RI

At this point, the client now knows that the server supports secure
renegotiation and can simply send RI in any renegotiation handshake
(and if the client doesn't implement the full extensions framework, it
could just add a known byte string to the end of the ClientHello,
without requiring full extension support). Note that this is
reminiscent of the SSLv2->SSLv3 transition where clients would
initially offer backward compatibility handshakes but once they knew
the server was SSLv3-capable would offer the new ClientHello.

What about 5246 and unsolicited extensions?
As far as I can tell, the major argument against using extensions
for S->C signalling is the 5246 prohibition against the server providing
unsolicited extensions. However, that was clearly intended to prevent
the server from sending extensions the client didn't expect and
that's not the case here. Moreover, we're updating 5246 so we can relax
the restriction for this extension (though I would think not in general).

What about not putting the verify data in the extension?
I think that issue is separable from the question of how we signal
support, so would like to deal with it separately. (It seems this
won't make any difference for the bigger questions like can deploying
the fix break things that currently work, or whether you can implement
the fix purely inside the TLS library)

What about SSLv3?
Obviously, the ClientHello is compatible with SSLv3.  (and the magic
cipher suite can be offered even in SSLv2 backward compatible
hello---ugh!). Although SSLv3 does not have the TLS extension
framework, we could also specify that the server (once it sees the
magic cipher suite indicating the client supports this draft) just
appends the relevant fixed-length byte string to the end of the
ServerHello.

What do people think about this approach?

-Ekr

[*] I didn't invent this approach, I'm just reproposing it to try to focus
discussion.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 25 Nov 2009 23:44:33 +0100

Eric,

I think this is a great approach and in line with recent proposals.
I prefer the RI extension without the verify data for reasons previously
stated on the list.

/Stefan

On 09-11-25 11:35 PM, "Eric Rescorla" <[email-masked]> wrote:

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

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 25 Nov 2009 22:53:55 +0000

> cause a connection failure with a downrev (extension noncompliant)
[details snipped]

I like it! This addresses all my concerns.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Robert Relyea <[email-masked]>
Date: Wed, 25 Nov 2009 15:28:28 -0800

> extension-less handshake.
This is not an RI specific issue. TLS already defines a number of
extensions. This fallback policy was implemented not because extension
noncompliant servers were particularly important, but because
implementations needed to have minimal objections for moving forward and
actually using extensions. Today TLS clients regularly use extensions,
so adding one more to allow renegotiation should not be an issue.
> to the app logic are required.
I think we already have a handle on this. Most modern browsers already
send extensions in their initial handshakes. This change has been
responsible for the final demise of SSLv2.

The whole idea that extensions are rare just doesn't match with today's
reality. Yes, there are some implementations that can't handle them.
That is a very small percentage compared to the number of
implementations that can't safely renegotiate (e.i. 100% of them). Those
implementations already have to deal with a world in which extensions
are real and common. They also have to deal with a world in which their
code will need to be patched in order to be safe anyway.

> draft-mrex-tls-secure-renegotiation). 
I'm not excited about the magic cipher suite hack for SSLv3, but I can
live with it if I have to. I am strongly opposed to extending it to TLS.
In the TLS world extensions are expected, normal, and now common. There
is no reason to overload a field created specifically to determine a
compatible cipher suite with something that extensions are designed to do.

bob

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Nov 2009 16:05:53 -0800

At Wed, 25 Nov 2009 15:28:28 -0800,
> compatible cipher suite with something that extensions are designed to do.

I'd be very interested in seeing data on what fraction of existing
servers can't handle extensions. Is there any chance that you have
measurements?

Thanks,
-Ekr

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Thu, 26 Nov 2009 01:34:07 +0100

> the ServerHello). In other words:

To me this looks like something that can work.

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

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 21:31:30 -0500

>What about not putting the verify data in the extension?
I prefer this going into the extension.

> What do people think about this approach?
I think this approach is good.

------------------------------------------------
Peter Robinson - [email-masked]
Engineering Manager
RSA, The Security Division of EMC - http://www.rsa.com/
Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, 
AUSTRALIA.
Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400.

---

From: <[email-masked]>
Date: Thu, 26 Nov 2009 08:03:48 +0100

<wearing Area Director hat>

I agree that minimal risk of breaking things that currently work is
important for timely deployment of the fix.  The proposed change seems
to address many of the concerns raised so far, and significantly
improves on the -00 draft.

If it's quite unlikely to break things that currently work, and
reasonably simple to implement (e.g., avoids the need for fall-back to
extension-less handshake, which can't be necessarily implemented by
the TLS library -- this is a big change to the -00 draft), I'd say
we're reaching "good enough", and timely publication is more important
than the exact bits.

Unless the WG believes these goals are not actually met (that is, this
still could break too many things, or is excessively complex to
implement/deploy), I'd like to see an updated draft soon, and start
IETF Last Call.

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Eric Rescorla
> Sent: 26 November, 2009 00:35
> To: [email-masked]
> Subject: [TLS] Avoiding first use of RI in ClientHello
> 
> Folks,
>

---

From: <[email-masked]>
Date: Thu, 26 Nov 2009 08:18:38 +0100

Robert Relyea wrote:

> extensions. This fallback policy was implemented not because
> extension noncompliant servers were particularly important, but
> because implementations needed to have minimal objections for moving
> forward and actually using extensions. Today TLS clients regularly
> use extensions, so adding one more to allow renegotiation should not
> be an issue.

It probably isn't for clients that *already* use extensions.  The
major PC/Mac/Linux web browsers do, but those are not the only TLS
clients out there.

I can see that it could be a big issue for clients that today do not
send extensions. Not because extensions themselves are difficult to
implement, but as Eric pointed out, the fallback logic could be very
difficult to implement (and may require changing applications), and
most importantly, if you don't send extensions currently, you don't 
really know whether you need the fallback logic before you've broken 
things that work today...

Best regards,
Pasi
(not wearing any hats)

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 26 Nov 2009 09:28:36 +0100

Eric and all,

On 09-11-25 11:35 PM, "Eric Rescorla" <[email-masked]> wrote:

> support, so would like to deal with it separately.

I would like to elaborate my support for an RI with absent verify data.

The major argument I have seen for including verify data in the RI extension
is that it would allow us to preserve the current Finished calculation. This
will allow us to use more of the current implementation code and provide a
more clean design.

I think these to a major extent are valid arguments, but I find the opposing
arguments even more convincing. These are:

1) Empty RI It's good security design

If you want to make sure two parties agree on a value that they have derived
from a previous state, in order to bind to the previous state, then why
would you exchange that value before doing the check?

On the contrary, I find it to be good security design not to exchange that
value as it:

1) Reduce information leakage to an attacker
2) Increase the security assumptions that can be made based on a proof of
matching values (good Finished messages).

Even if there are no attack today to exploit the information leakage and
exchanging the values allows secure design, I still find it valuable to
apply the best possible security design to reduce the chance of future
problems. 

2) Better migration path towards future

If we would design TLS 1.3, then would we send this data in the handshake,
or would we not?

I suspect we would not, due to argument 1)
Exchanging this value serves no purpose other than saving a few lines of
code changes from TLS 1.2.

Consequently, if we design an updated Finished calculation now, we can keep
that in TLS 1.3 and just remove the signaling we now add for SSLv3 -> TLS
1.2.

3) Less likely to cause implementation problems

This is just my guessing based on what I have heard.
But if the client verify data is provided in RI, then it is not enough to
recognize the extension. It is now also necessary to parse it, extract the
data and to use it in a critical security check.

I can't really judge how likely this is to cause more implementation
problems or even implementations that appears to do the security check
against previous handshakes, but actually just feeds it into the finished
calculation blindly.

But it feels like good design to eliminate/reduce this type of problems if
possible. Especially if it is better security design at reasonable cost.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 26 Nov 2009 09:46:20 +0100

Just elaborating that I think, based on these arguments, that the verify
data should neither be added to the PRF or any other current handshake
message.

I.e. I support Michaels proposal in this regard.

/Stefan

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Nov 2009 10:51:11 +0200

> apply the best possible security design to reduce the chance of future

Agree

> that in TLS 1.3 and just remove the signaling we now add for SSLv3 -> TLS

Agree

> possible. Especially if it is better security design at reasonable cost.

As far as implementation complexity, it's a wash. You have to have some long-term "state", which now must include the old verify_data. There's no way around that.

It's not that much different to add this to the calculation of the Finished message, either in concatenation to the handshake messages, or instead of the finished label, as it is to compare it to the contents of the RI extension.

There is the risk that an implementer who hasn't been following this list might fail to verify the data in the extension. Googling 'security bug "fails to verify"' returns 34,000 hits, suggesting that this is a valid concern.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Nov 2009 08:18:11 -0800

At Thu, 26 Nov 2009 08:03:48 +0100,
> implement/deploy), I'd like to see an updated draft soon, and start

I've just submitted an updated draft with this change.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Thu, 26 Nov 2009 11:10:30 -0600

Yoav Nir wrote:
> 
> As far as implementation complexity, it's a wash. You have to have
> some long-term "state", which now must include the old verify_data.
> There's no way around that.

Perhaps, but that state does not need to be more that a bit or two in
each direction for the signaling.

State derived from the previous handshake is already available at both
endpoints. It is not necessary to carry over more!

This state currently resides in:
    client write MAC secret
    server write MAC secret
    client write key
    server write key

These secure entropy within these parameters are considered sufficient
to protect all the application data, why aren't they good enough to
establish continuity-of-identity across the renegotiation?

Seems to me the MAC_secret is better than the Finished message if for no
other reason than it's 20 bytes instead of 12. Currently, all this
hard-won entropy is discarded at the CCS. A tragedy!

My proposal:

At the CCS, instead of replacing the client/server MAC secret data,
simply XOR-merge the incoming values with the previous ones.

* A one-line software change.
* Easy even in hardware.
* Preserves more entropy.
* No changes to PRF.

Please actively attempt to shoot it down.

- Marsh

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 26 Nov 2009 17:27:34 +0000

> Please actively attempt to shoot it down.

I think this will give problems for external crypto libraries like PKCS#11 where
session key derivation is a mechanism with fixed parameters and the actual keys
are not available in plain text outside the hardware. You'd need to develop a
new mechanism, add it to the PKCS#11 spec and update firmware on every piece of
crypto hardware.

Steve.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 26 Nov 2009 18:34:33 +0100

Reading the draft I realize I misunderstood one aspect.

I don't understand the benefit from having different signaling in the
initial handshakes and renegotiation handshakes.

Especially since I think it is better security design to not send the verify
data from previous handshakes.

Do you think sending the verify data is better security design? And why?

/Stefan

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 26 Nov 2009 19:01:32 +0000

> that in TLS 1.3 and just remove the signaling we now add for SSLv3 -> TLS

I really don't see any advantage in removing the signalling in TLS 1.3.
It doesn't simplify anything.

For removing the signalling to work, we would have to specify in the
*current* fix that:

 - sending a client version of {0x03, 0x04} or higher has the same
   meaning as sending the client->server signal.

 - negotiating {0x03, 0x04} or higher has the same meaning as sending
   the server->client signal.

That is just additional specification and implementation complexity, and
more cases that need to be tested, compared to using the signalling forever
and treating TLS 1.3+ in exactly the same way as TLS 1.0-1.2. Forget the
number of extra bits on the wire (which is negligable); it's the complexity
of the spec and of implementations, which necessarily have to support
multiple versions, that matters.

The original SSLv3 design messed up renegotiation; we'll just have to live
with some ugliness as a result of fixing it.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Marsh Ray <[email-masked]>
Date: Thu, 26 Nov 2009 13:07:06 -0600

> new mechanism, add it to the PKCS#11 spec and update firmware on every piece of

PKCS#11 looks like it defines structures for CK_SSL3_KEY_MAT_PARAMS and
CK_SSL3_KEY_MAT_OUT (these are also used by TLS).

So there are interfaces defined in hardware (or monolithic libraries)
that support feeding additional data into the Finished.verify_data
calculation but do not allow access to the MAC secrets?

*sigh*

Why was the Finished data shortened from 36 bytes in SSLv3 to 12 bytes
in TLS 1.0 anyway?

- Marsh

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 26 Nov 2009 19:24:55 +0000

> CK_SSL3_KEY_MAT_OUT (these are also used by TLS).

Yes, it provides handles to the keys but the keys are not necessarily
accessible. Some applications set the parameters so the keys are never
extractable for security reasons. Some security standards *require* that keys
can never leave the token.

That kind of thing causes problems with adding new algorithms (or algorithms
with new inputs). Changing the inputs (as opposed to adding new ones) is less
likely to cause a problem.

Adding new mechanisms or modifying existing ones in incompatible ways is
problematical if there is another standards process where it all has to be
approved/discussed. If the hardware is FIPS 140-2 validated and needs a new
validation to add a new mechanism that's a real pain.

As regards PKCS#11 I'm wondering if the use of interfaces like C_DecryptVerify()
(which improve throughput by decrypting and MACing in one go) places additional
restrictions on what can be done. I'm thinking here if they cause problems with
feeding additional data into a handshake which isn't part of the actual
handshake and might mess up state with e.g. stream ciphers.

Steve.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 26 Nov 2009 21:36:22 +0100

If you fix the Finished message calculation, making it immune to the
renegotiation attack, and making it the standard Finished calculation for
1.3.... Then why would you need to signal that you are using the standard
Finished calculation?

/Stefan

---

From: Marsh Ray <[email-masked]>
Date: Thu, 26 Nov 2009 15:22:51 -0600

> 1.3.... Then why would you need to signal that you are using the standard

So that clients and servers can be upgraded over a period of time
without causing interoperability problems.

- Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 26 Nov 2009 23:07:32 +0100

> without causing interoperability problems.

There are more than two ways how to treat signaling (how to signal  
that a new Finished computation should be used) with respect to future  
protocol versions, i.e., TLS 1.3 and later:

- The specifications could mandate keeping the explicit signal even  
with TLS 1.3+.

- The specifications could require an explicit signal only for those  
TLS 1.3+ implementations that do offer backwards compatibility with  
earlier protocol versions (i.e., if the *negotiated* protocol version  
is TLS 1.3 or later, that would imply that the new Finished  
computation should be used).

- The specifications could require an explicit signal only for  
implementations that don't announce TLS 1.3+ (i.e., if the *requested*  
protocol version is TLS 1.3+, that would imply that the new Finished  
computation should be used).

Stefan's proposal in the original message, it seems, was the third  
variant.  David's comment suggested that because of the complexity  
that comes with that variant, we should stick to the first one (and  
always keep signaling).

That's not implied, though.  The second variant makes a lot of sense  
to me -- it's just not something that the current specification would  
or should have to say a final word on: that's best left to the TLS 1.3  
specification.

Bodo

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 26 Nov 2009 20:52:12 -0800

On 2009-11-26 11:24 PST, Dr Stephen Henson wrote:

> extractable for security reasons. Some security standards *require* that
> keys can never leave the token.
> 
> That kind of thing causes problems with adding new algorithms (or
> algorithms with new inputs). Changing the inputs (as opposed to adding
> new ones) is less likely to cause a problem.
> 
> problematical if there is another standards process where it all has to
> be approved/discussed. If the hardware is FIPS 140-2 validated and needs
> a new validation to add a new mechanism that's a real pain.
> 
> As regards PKCS#11 I'm wondering if the use of interfaces like
> C_DecryptVerify() (which improve throughput by decrypting and MACing in
> one go) places additional restrictions on what can be done. I'm thinking
> here if they cause problems with feeding additional data into a handshake
> which isn't part of the actual handshake and might mess up state with
> e.g. stream ciphers.
> 
> Steve.

Yes, this is a very grave concern.  PLEASE do not propose any changes that
would necessitate new PKCS#11 mechanisms, which, in turn, would necessitate
new FIPS 140-2 or 140-3(!) security evaluations and certifications.  That
would slow the deployment of a new fix in certain (governmental)
environments by YEARS (no kidding).

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 26 Nov 2009 21:06:53 -0800

> without causing interoperability problems.

But clients and servers that are written to speak 1.3 (which doesn't exist
today) would be written to do the right thing from day 1, when they
negotiate version 1.3.  There would be no "upgrade over a period of time"
for clients and servers that negotiation version 1.3.

I'd propose the use of RI in 1.3 this way.

A 1.3 client that also implements lesser versions MUST send RI in the client
hello, in case the server does not implement 1.3, but implements some lesser
version.

A 1.3 server that also implements lesser versions MUST send RI in the server
hello when the client hello asks for a version less than 1.3 and the server
hello agrees to negotiate a version less than 1.3.

A 1.3 server that receives a client hello bearing version 1.3 (or greater)
NEVER returns RI in the server hello when the server hello negotiates
version 1.3 (or greater).

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Nov 2009 08:28:20 +0100

Thanks Nelson for writing it out.
This was exactly what I meant.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Nov 2009 09:54:41 +0100

The current draft-ietf-tls-renegotiation-01.txt still promotes RI extension
containing verify_data from previous handshake.

Sorry for repeating my question, but I would be really interested to know
why this is considered a better security design, than to simply send an
empty RI (and to feed the values directly into Finished calculation without
exchange).

To me it seems obvious that the best security design is to NOT exchange this
data if the objective is to verify that the parties already hold the data.

It's feels like "I want proof that you hold this value, so I'm going to send
it to you".

/Stefan

---

From: <[email-masked]>
Date: Fri, 27 Nov 2009 10:16:31 +0100

Stefan Santesson wrote:

> To me it seems obvious that the best security design is to NOT
> exchange this data if the objective is to verify that the parties
> already hold the data.
> 
> It's feels like "I want proof that you hold this value, so I'm going
> to send it to you".

<not wearing AD hat>

In many cases (such as cipher suites with NULL encryption, or some
apps that use channel bindings) the verify_data values are already
public. So the objective is *NOT* to prove that "I know this value";
the objective is to verify that both ends have the same value.

<wearing AD hat>

About the obviousness of the best security design, it's safe to say 
that when it comes to design style and preferences, people often 
disagree. I think we're reaching "good enough" here -- if people have 
serious concerns that the latest draft does not work, those are
important, but as AD, I'm not going to give much weight to "it could
be nicer" type of arguments in a situation where timely publication 
is important. 

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 27 Nov 2009 10:30:13 +0100

<[email-masked]> writes:

> public.

I don't think there are "many" cases where the verify_data is public
today.  NULL encryption is typically disabled in all TLS stacks and
there are no apps that use tls-unique channel bindings to my knowledge.
Any pointers to deployed applications?

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Nov 2009 11:02:44 +0100

Pasi,

> the objective is to verify that both ends have the same value.

This is what I meant by "holding the value". The evidence thereof is
degraded if you exchange the value instead of just making sure that, as you
say, "both ends have the same value".

> be nicer" type of arguments in a situation where timely publication

Well, I don't bring this up just because it would be a bit nicer.

I bring this up since NOT exchanging verify_data seems to offer:

1) better security 
2) simplicity - allows the signaling to be identical for all handshake
exchanges regardless of protocol version.
3) better compatibility/easier migration towards future versions of TLS

Sending the verify_data seems to offer no advantage other than to preserve
the old (and agreed to vulnerable) Finished calculation instead of fixing
it.

I just genuinely interested to understand why we would choose the less
secure and more complex option, alternatively whether I got everything
totally wrong. 

/Stefan

---

From: <[email-masked]>
Date: Fri, 27 Nov 2009 15:09:58 +0100

> 3) better compatibility/easier migration towards future versions of TLS

IMHO all these are your opinions, not facts (in some cases, my personal
opinion could be the same as yours, though -- but that doesn't mean
everyone else agrees, too).

This *might* bring better security if you assume implementors that are
stupid in a very particular way. But if they're stupid in some other
way, there's necessarily no difference. And seriously speaking, the 
current draft is so simple that if an implementor can't get it right,
he/she has no business in implementing security-critical components...

For simplicity, the current draft is already very simple, and IMHO
it's not clear that continuing to tweak it has a positive return
on investment, considering it delays the publication. 

About future versions of TLS, IMHO it's quite difficult to predict which
would be most compatible. What if, e.g., the next version of TLS
decides that sending certificates in the clear wasn't that great idea,
and nowadays we can afford to do Diffie-Hellman before doing any
authentication? This could completely change all the handshake
messages after ClientHello, and the current functionality of "Finished"
could be done in quite different way.. 

(I'm not suggesting that TLS 1.3/2.0 should do that -- just that
we don't know what it will do yet.) 

Best regards,
Pasi
(not wearing any hats)

---

From: <[email-masked]>
Date: Fri, 27 Nov 2009 15:16:31 +0100

> Any pointers to deployed applications?

Not really. SCRAM (currently in RFC Ed queue) will use it. Perhaps
OAUTH WG will use it, too.

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Nov 2009 15:25:09 +0100 (MET)

> on investment, considering it delays the publication. 

Not really.

I ask this before: what should the original designers of the
SSLv3 renegotiation have done from the beginning to make it
secure.  Invent TLS extensions and then a TLS extension RI
is definitely _not_ the answer.  They would have fixed the
handshake message hash from the beginning.

The "dirty ugly" signaling is a patch for a "dirty ugly" security problem
in "dirty old" implementations of a "dirty old" protocol.
We need it to distinguish old from updated implementations and for
supporting interop with old -- otherwise we could just change
both handshake algorithms (like including different finished
labels) and make the fix entirely without on-the-wire changes,
no signaling, but also no interop with the installed base.

> could be done in quite different way.. 

If it does not retain (Extended)ServerHello, then it will actually
kill a lot of the existing SSL/TLS protocol features
-- and reliably kill TLS extension RI with it.

The handshake message hash is one of the basic concepts of the
SSL/TLS protocol.  If that is changed, then you basically have
none of the original protocol left.

Therefore directly feeding into the handshake message hash is
the more conservative and forward compatible approach.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 27 Nov 2009 16:30:39 +0200

> 1) Reduce information leakage to an attacker

Hello,
 How would that be? What scenario do you have in mind? This value has
already been exchanged in the initial finished message exchange and
was protected under the same ciphersuite. Why would this exchange be
less secure? If the attacker can decrypt and see this value, then he
can also see the initial finished value. No new information is given
to him.

regards,
Nikos

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Nov 2009 16:00:38 +0100

Pasi,

> on investment, considering it delays the publication.

It's not a matter of tweaking,

This working group discussion has produced 2 proposals.

If you count in changes that is about to be applied to Marin's document the
following apply:

1) Both proposals agree on the same initial signaling (cipher suite for C->S
and empty RI for S->C)

2) For renegotiations:
   a) Martin's draft propose to update (fix) the Finished calculation
      and use the same signaling as in 1).
   b) Eric's draft suggest sending verify_data in RI extensions and keep the
      old Finished calculation.

Many members of this list argue that 2a has better security properties and
is simpler to deploy (especially for legacy implementations).
The arguments for 2b seems to be that it is "good enough" and "why should we
care about old legacy implementations".

Now, maybe I'm wrong about that, but wouldn't it at least be fair to ask the
working group which approach they prefer?

/Stefan

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Nov 2009 07:11:12 -0800

At Fri, 27 Nov 2009 09:54:41 +0100,
> empty RI (and to feed the values directly into Finished calculation without

I think I answered this question with my view in an earlier message:

  This requires breaking the current clean definition of handshake
  hashes as the hash of all the handshake messages and simply adding
  some synthetic message in the middle. I don't think this is anywhere
  near as clean, as evidenced by the ongoing debate about whether to put
  it the synthetic data in the front, the back, incorporate it into the
  PRF, or chain the pre-existing handshake messages. [FWIW, I think I
  prefer the last of these implicit versions.]
  
  By contrast, RI allows that part of the system (which is well
  understood) to remain the same and in fact when RI is offered on the
  first handshake, there is no change to the TLS core at all. It's all
  just hashed into Finished as part of the ordinary TLS procedures,
  and everything is in fact compliant TLS, which I think is desirable.
  
  I appreciate that this is to some extent a matter of tradeoffs,
  but I don't find the arguments in favor of the implicit version
  very compelling when weighed against the above.

I also share David Hopwood's concern about ambiguity in the handshake
hashes stream created by having data which is not properly formatted
injected into the hash
(http://www.ietf.org/mail-archive/web/tls/current/msg04857.html),
so I don't think the particular approach in Martin's draft is
really satisfactory.

This isn't to say that one couldn't design a mechanism that didn't
carry the signaling data over the wire--one obviously could. 
However, when I look back over the 50 or so messages that were
sent to the list yesterday, a large fraction of them are various
tweaks on exactly how incorporate that data, which suggests to
me that this approach isn't at all easy to reason about.

-Ekr

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Nov 2009 16:08:54 +0100

No I don't have any scenario (and I said so).

This was part of a principal (theoretical) argument.

/Stefan

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Nov 2009 07:22:35 -0800

At Fri, 27 Nov 2009 16:00:38 +0100,
> care about old legacy implementations".

I don't think this characterizes my position particularly well:

- I don't think that having the data not carried in the message obviously
  has better security properties. There may be some version that clearly
  does, but I haven't seen it yet. My suspicion is that the "best" versions
  of each of these approaches have equivalent security, but as I said
  in a previous message, I'm concerned about the specific "implicit"
  versions I've seen proposed.
  
  [For the record: your argument about reducing information leakage
  is, AFAICT, incorrect. The verify_data in the Finished is carried
  over the same encrypted channel as the new handshake messages. Any
  attacker who can see the second can see the first.]

- I don't agree that it's simpler to deploy versions that don't carry the
  verify_data in an extension. It may require fewer lines of code
  (though honestly, the number of lines we're talking about here
  is so few, it hardly matters), but on the other hand, the lines
  of code are in core pieces of TLS, not in peripheral pieces.

- I'm not sure where you get the idea that carrying the verify_data
  in an extension somehow involves not caring about legacy implementations.
  Perhaps you and I have different views of what that would involve.
  As I observed earlier, TLS connections that use RI (and not the magic
  cipher suite) are fully compliant with all existing TLS RFCs.
  That seems pretty legacy-friendly to me.

In short, I don't think that signaling the previous verify_data in the 
extension is merely "good enough". I think it's better.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Nov 2009 16:23:36 +0100 (MET)

> on investment, considering it delays the publication. 

We should _not_ rush it out.

The message that I'm getting from people doing maintenance of
old installed base is that it is not easy for them to make
an assessment about TLS extension RI.  The spec is from a high
level view.  For implementations that don't support TLS extensions,
you can only find out and what it means in terms of code changes
when you try to implement it--not from that draft.

When I (re)wrote my I-D, I tried to describe all the necessary
code changes in order to implement it.  Well, OK, it's a little more
than that, more like a "nanny" spec.

It should _not_ be a question how beautiful the solution is and how well it
fits into new implementations, but primarily, that it fits equally
well even the oldest implementations around, and that it is easy
for them to implement, otherwise we are not going to see the
widespread adoption that we need.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Nov 2009 07:24:48 -0800

At Fri, 27 Nov 2009 16:08:54 +0100,
> This was part of a principal (theoretical) argument.

As Nikos says, I don't see how this argument has any force:

The basic design of TLS rehandshaking is that it's performed 
over the same channel as the original handshake. Therefore, by
definition the attacker already has the contents of the immediately
previous Finished.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Nov 2009 16:27:03 +0100 (MET)

> so I don't think the particular approach in Martin's draft is

That problem can be trivially fixed.

We just memorize the non-encrypted Client.Finished and Server.Finished
handshake messages in full, rather then just the contained verify_data.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Nov 2009 16:41:15 +0100 (MET)

Eric Rescorla wrote:
>   some synthetic message in the middle.

"The current clean definition" of the handshake message hash is
what has gotten us into the trouble.

So we are not breaking it, we are fixing it.  We're not doing any
wire-format changes, so implementations that have not implemented
renegotiation at all are not even affected by this change.  That
is definitely much cleaner as having everyone run around with
a band-aid on their ClientHello and ServerHello handshake
messages when renegotiating.  It's encrypted, so most people
will not see it, but it's still there!

                                         I don't think this is anywhere
>   prefer the last of these implicit versions.]

Making a rarely-used option that came several years after most of
the currently installed base a retroactive mandatory-to-implement
feature of the protocol, THAT is dirty and ugly.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Nov 2009 16:51:38 +0100 (MET)

> me that this approach isn't at all easy to reason about.

We just carry the original handshake messages and be done with it.

As David outlined stripping the original message header from
the verify_data wasn't such a good idea, because it opens a
theoretical possibility of an attack.  Fine, we leave the
header on.

Messing around with the PRF, that is ideas from implementors
that never came in contact with FIPS 140-2 and interfaces to
crypto hardware and requirements around that.

And it would make everything much more complicated because of
the differences between SSLv3 and TLS. 

Adding the previous Finished messages at the very beginning of
the handshake message hash is less straight-forward.

When the client sends the renegotiation ClientHello, it must
have previously sent the Client.Finished, so we could add that,
however it may have not yet received the Server.Finished from
the previous handshake, so this must go into the handshake
message hash after ClientHello in order to be on the safe side.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Nov 2009 16:53:03 +0100

Eric,

Thanks for the straightforward reply.
In-line;

>   versions I've seen proposed.

I have a hard time believing that it would be a hard to define a structure
for inclusion of past verify_data that would work for implicit inclusion.

The real security advantage of implicit is that you know that the opponent
actually derived the same value from previous handshake. By sending it in RI
you don't know if the opponent just blindly accepted what you sent without
checking it. 

I think that is a significant security advantage for the implicit approach.

>   attacker who can see the second can see the first.]

We can disregard that comment for this discussion. For this I agree with
you.

>   That seems pretty legacy-friendly to me.

An RI from the client containing verify_data need to be parsed and values
have to be extracted by the server. This means requirement to add extension
handling at the server side for all versions of SSLv3 -> TLS 1.2.

In the alternative solution no server need to be bothered with parsing
extensions. Some people mean that this is much easier to implement for
legacy implementations. I just find their arguments convincing.

> extension is merely "good enough". I think it's better.

Fair enough.
I'm afraid I still disagree.

/Stefan

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Nov 2009 07:54:22 -0800

At Fri, 27 Nov 2009 16:41:15 +0100 (MET),
> what has gotten us into the trouble.

I don't agree with this assessment of what the problem is.

> That

Yes it's still there. So what?

Obviously, you and I have different opinions about what's "clean".

> feature of the protocol, THAT is dirty and ugly.

This seems like a generalized argument against using extensions at
all, not against putting the verify_data in the handshake.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Nov 2009 07:55:28 -0800

At Fri, 27 Nov 2009 16:23:36 +0100 (MET),
> when you try to implement it--not from that draft.

Hmm... This doesn't seem that hard to work out.

In any case, I'd certainly be willing to add a non-normative appendix
describing the minimal code changes necessary.

> widespread adoption that we need.

I'm not sure I buy this: the vast majority of TLS implementations run
one of a small number of stacks (SChannel, OpenSSL, NSS). The pace of
adoption is going to be primarily driven by (1) how fast those stacks
implement this new functionality and (2) the base (very slow) rate at
which people upgrade their stacks [Res03]. Whether or not a stack that
has <1% of the market upgrades only has a very small impact on
how widespread deployment is.

This isn't to say that we shouldn't be concerned with whether
what we do can be incorporated into old systems, but I don't
really agree that easy incorporation into such systems ought
to be our highest design priority.

-Ekr

[Res03] E. Rescorla, "Security Holes... Who cares?", Proceedings of
the 12th USENIX Security Symposium, August 2003.

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Nov 2009 17:15:08 +0100 (MET)

Eric Rescorla wrote:
> one of a small number of stacks (SChannel, OpenSSL, NSS).

You're only looking at WebServers and WebBrowsers.
Maybe because Statistics like Netcraft have such a limited perception.

Btw. these "small number of stacks" is in reality a larger number
of independently maintained codelines.  Schannel may be ~30,
OpenSSL is probably >> 500, and most of them are quite old.

There are probably several independent SSL implementations for Java.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Nov 2009 08:17:24 -0800

At Fri, 27 Nov 2009 16:27:03 +0100 (MET),
> handshake messages in full, rather then just the contained verify_data.

Woah, that's scary....

We're going to take the exact messages that previously appeared on the
wire and inject them into the handshake hashes in order to *reduce*
ambiguity in the hash input stream? I mean, maybe that's OK, but it
sure isn't obviously OK.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Nov 2009 17:34:20 +0100 (MET)

> ambiguity in the hash input stream? I mean, maybe that's OK, but it

What we would be doing is limiting the ambiguity with something
arbitrary to the ambiguity with a very well-defined handshake
message (actually, two of them).  

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Nov 2009 18:10:54 +0100 (MET)

> ambiguity in the hash input stream? I mean, maybe that's OK, but it

A possible solution to avoid the ambiguity might look like the
following:

-Martin

ssl/s3_srvr.c:ssl3_send_server_hello()

    ret = ssl3_do_write(s,SSL3_RT_HANDSHAKE);
    if ( ret>0 ) {
        if ( s->s3->peer_is_updated || 0==s->s3->allow_old_renego ) {
            if ( s->s3->renegotiate ) {
                /* add previous Client.Finished to handshake msg hash */
                ssl3_finish_mac(s,s->s3->peer_finished,
                                  s->s3->peer_finished_len);
                /* add previous Server.Finished to handshake msg hash */
                ssl3_finish_mac(s,s->s3->finished,
                                  s->s3->finished_len);
            } else {
                /* add initial handshake msg hash differentiator */
                ssl3_finished_mac(s,"\x01\x55\xAA\x55", 4 );
            }
        }
        else
        {
            if ( s->s3->renegotiate ) {
                /* Servers SHOULD NOT offer old renegotiation anymore */
                /* if (0==(s->options&SSL_OP_ALLOW_INSECURE_RENEGOTIATE))*/
                ssl3_send_alert(s,SSL3_AL_FATAL,SSL_AD_HANDSHAKE_FAILURE);
                ret = -1;
            }
        }
    }
    return(ret);

---

From: <[email-masked]>
Date: Fri, 27 Nov 2009 18:30:43 +0100

Martin Rex wrote:

> I ask this before: what should the original designers of the SSLv3
> renegotiation have done from the beginning to make it secure.
> Invent TLS extensions and then a TLS extension RI is definitely
> _not_ the answer.  They would have fixed the handshake message hash
> from the beginning.

I think "what would the SSLv3 designers have done" (almost 15 years
ago) and "what should we today" are two completely different
questions, which may have completely different answers.

> The "dirty ugly" signaling is a patch for a "dirty ugly" security
> problem in "dirty old" implementations of a "dirty old" protocol.
> supporting interop with old -- otherwise we could just change both
> handshake algorithms (like including different finished labels) and
> make the fix entirely without on-the-wire changes, no signaling, but
> also no interop with the installed base.
> 
> > About future versions of TLS, IMHO it's quite difficult to predict
> > which would be most compatible. What if, e.g., the next version of
> > TLS decides that sending certificates in the clear wasn't that
> > great idea, and nowadays we can afford to do Diffie-Hellman before
> > doing any authentication? This could completely change all the
> > handshake messages after ClientHello, and the current
> > functionality of "Finished" could be done in quite different way..
> 
> kill a lot of the existing SSL/TLS protocol features -- and reliably
> kill TLS extension RI with it.
> 

We haven't had *any* discussions in the WG about what the next version
of TLS could or should or might change, so I don't think we can have
even any "informed guesses" about it.

So while your proposal may be conservative, IMHO claiming it's
"forward compatible" cannot be based on anything except totally
wild guesses... (and other people making totally wild guesses
about the topic might reasonably guess very differently)

Best regards,
Pasi
(not wearing any hats)

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Nov 2009 19:04:56 +0100 (MET)

> questions, which may have completely different answers.

If we were discussing a new feature for TLSv1.2 or TLSv1.3 only,
I would agree.

But we're actually going back to code that is 10 years or more
and want that fixed as well.  So we need to pay a little more
attention to the perils of poor souls from the dirty old cruft department
than to the dreams of the nerds from the fancy new features department.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Nov 2009 11:27:23 -0800

At Fri, 27 Nov 2009 17:34:20 +0100 (MET),
> message (actually, two of them).  

Hmm...

Thinking about this some more, consider the case of a client which
(improperly) ignores handshake messages which come out of sequence,
but still hashes them into handshake hashes.

In the simple attack where the server thinks there is a rehandshake
and the client thinks it is the initial handshake, what if the 
attacker between the client and the server injects the
replayed Client.Finished and Server.Finished messages into the message
stream going towards the client. The client would then ignore but hash
the messages with the result that the data hashed by the client being
the is the same as the data being hashed by the server and the attack
succeeds. Am I missing something here?

Obviously, one could just say that the client is misbehaving here
and so this doesn't matter (though I would note that others have expressed
concerns about what happens with implementation errors, and this is only
requires an error by one side, not both). However, I think it's illustrative
that we need to be pretty careful about introducing ambiguity between
messages that are on the wire and those that are merely hashed.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Nov 2009 21:02:48 +0100 (MET)

> but still hashes them into handshake hashes.

I did consider that, see the solution here:
http://www.ietf.org/mail-archive/web/tls/current/msg04920.html

this will make the initial and renegotiation handshake message
hash reliably distinct.

And btw. when a TLS peer ignores two incorrect finished messages
on a connection, then there are a lot more things to worry about.
Those are completely unlikely to get the TLS extension RI right.

-Martin

---

From: <[email-masked]>
Date: Fri, 27 Nov 2009 21:10:55 +0100

Martin Rex wrote:

> If we were discussing a new feature for TLSv1.2 or TLSv1.3 only, I
> would agree.
> 
> But we're actually going back to code that is 10 years or more and
> want that fixed as well.  So we need to pay a little more attention
> to the perils of poor souls from the dirty old cruft department than
> to the dreams of the nerds from the fancy new features department.

I fully agree that deployment (even with old implementations) needs to
be taken into account -- otherwise we'd be ignoring reality.

But *none* of the proposals made so far would be the solution SSLv3
designers would have picked, had someone pointed out this problem
before implementations had shipped. For starters, they would not have
needed signalling (in either direction), which is one of the main
issues we're facing today...

Best regards,
Pasi
(not wearing any hats)

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 27 Nov 2009 22:46:17 +0100

> data from previous handshakes.

You didn't misunderstand this here -- Eric focussed on the signaling  
issue here, saying the issue of whether the verify_data should be  
included in extensions is a separate one.  (Which, I guess, is also  
why you changed the "Subject" line for further discussion of that  
topic :-) )

Anyway, I'm really writing now to confirm that the signaling approach  
as used in draft-ietf-tls-renegotiation-01.txt looks fine to me.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 27 Nov 2009 23:03:55 +0100

> messages that are on the wire and those that are merely hashed.

While this looks a little far-fetched to me, many security issues  
found in practice seem far-fetched if you don't know that they're real  
-- what you're writing here is enough to convince me that if there's  
one canonical way to solve the security problem, it's with including  
explicit verify_data in renegotiation handshake hello extensions.

The one thing I don't agree with in draft-ietf-tls- 
renegotiation-01.txt regarding the extensions is having the  
ServerHello concatenate the client and server verify_data.  That's  
pointless given that the client sends its one verify_data in its  
extension -- the server should only send its own verify_data.

I have one more concern with draft-ietf-tls-renegotiation-01.txt:

The ID says
"By default, TLS implementations conforming to this document MUST  
verify that once the peer has been identified and authenticated within  
the TLS handshake, the identity does not change on subsequent  
renegotiations. For certificate based cipher suites, this means  
bitwise equality of the end-entity certificate. If the other end  
attempts to authenticate with a different identity, the renegotiation  
MUST fail. If the server_name extension is used, it MUST NOT change  
when doing renegotiation."
It makes sense to require this when a party conforming to this  
specification falls back to compatible mode, when it has determined  
that according to the handshake the peer does not conform to the  
specification.  However, if the client and server *both* confirm to  
the specification and thus have secure channel binding across  
renegotiations, there's no point in forbidding "identity" changes  
(which may not be really identity changes, but other create and yet  
valid uses of TLS renegotiation -- for example, consider a server that  
uses a particular ciphersuite [requiring a special certificate] only  
with authenticated clients [and thus in a renegotiation handshake], to  
name just one example).  There's no 1-to-1 mapping between certificate  
and "identities" -- at best a certificate is a particular "name", but  
a single entity can legitimately use multiple names.

Bodo

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 27 Nov 2009 16:33:15 -0800

Bodo Moeller wrote:
> "By default, TLS implementations conforming to this document MUST verify 
> that once the peer has been identified and authenticated within the TLS 
> handshake, the identity does not change on subsequent renegotiations. 
> For certificate based cipher suites, this means bitwise equality of the 
> end-entity certificate. If the other end attempts to authenticate with a 
> different identity, the renegotiation MUST fail. If the server_name 
> extension is used, it MUST NOT change when doing renegotiation."
> specification falls back to compatible mode, when it has determined that 
> according to the handshake the peer does not conform to the 
> specification.  However, if the client and server *both* confirm to the 
> specification and thus have secure channel binding across 
> renegotiations, there's no point in forbidding "identity" changes (which 
> may not be really identity changes, but other create and yet valid uses 
> of TLS renegotiation -- for example, consider a server that uses a 
> particular ciphersuite [requiring a special certificate] only with 
> authenticated clients [and thus in a renegotiation handshake], to name 
> just one example).  There's no 1-to-1 mapping between certificate and 
> "identities" -- at best a certificate is a particular "name", but a 
> single entity can legitimately use multiple names.

In addition, a TLS 1.2 server may have two certificates for the *same* name;
one signed with SHA-1 and another signed with SHA-256.

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 28 Nov 2009 03:49:50 +0000

[top-posting fixed]

>>    the server->client signal.
[...]
> 1.3.... Then why would you need to signal that you are using the standard

Suppose that a client is "strict", i.e. only wants to connect to patched
servers. Since it doesn't know in advance that the server supports TLS 1.3,
then it must send the c->s signal in order to find out whether the server
is patched. If the c->s signal is not sent, then the s->c signal can't be
sent either, so the client wouldn't know whether the server was patched,
whenever TLS 1.2 or earlier is negotiated.

This is important because an initial handshake by a patched client can
correspond to a renegotiation at an unpatched server. So, it isn't
sufficient that the client uses the updated Finished computation for
renegotiations.

Sending a client version >= TLS 1.3 can be treated as implying the c->s
signal, and negotiating TLS 1.3 can be treated as implying the s->c signal,
but this won't eliminate any of the code that was handling signalling for
downrev versions. So this just adds code paths; it doesn't remove any.

Of course, it is possible that at some point in the fairly distant future,
TLS 1.3 will be the *minimum* version that a given implementation will
negotiate. At that point there would be a potential simplification -- but
it isn't at all clear that it outweighs the complication until then.
(Note: I have a "Buxton index" of about 20 years, and I still don't think
this eventual simplification is worthwhile.)

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 28 Nov 2009 04:05:24 +0000

Bodo Moeller wrote:
> There are more than two ways how to treat signaling (how to signal that
> a new Finished computation should be used) with respect to future

[numbering added]
> 1. The specifications could mandate keeping the explicit signal even with
> TLS 1.3+.
> 
> 2. The specifications could require an explicit signal only for those TLS
> 1.3+ implementations that do offer backwards compatibility with earlier
> protocol versions (i.e., if the *negotiated* protocol version is TLS 1.3
> or later, that would imply that the new Finished computation should be
> used).
> 
> 3. The specifications could require an explicit signal only for
> variant.  David's comment suggested that because of the complexity that
> comes with that variant, we should stick to the first one (and always
> keep signaling).
> 
> That's not implied, though.  The second variant makes a lot of sense to
> me -- it's just not something that the current specification would or
> should have to say a final word on: that's best left to the TLS 1.3
> specification.

No, we have to decide now. For approach 2 to work, *every* patched
implementation must know that requesting TLS 1.3+ implies that a
client is patched. For approach 3 to work, *every* patched implementation
must know that negotiating TLS 1.3+ implies that a server is patched.

If we leave it until TLS 1.3 is specified, then there will exist
implementations that don't know these things. Therefore, TLS 1.3+ clients
will have to send the c->s signal anyway, in case the server is one of
those that doesn't know that a TLS 1.3+ request implies that it is OK to
send the s->c signal. Similarly, TLS 1.3+ servers will have to send
the s->c signal anyway, in case the client is one of those that doesn't
know that negotiating TLS 1.3+ implies being patched.

Thus, "not deciding" is effectively equivalent to deciding on approach 1.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 28 Nov 2009 04:24:51 +0000

> must know that negotiating TLS 1.3+ implies that a server is patched.

Correction:
For approach 3 to work, *every* patched implementation must know that
requesting TLS 1.3+ implies that a client is patched.

> know that negotiating TLS 1.3+ implies being patched.

The second part of this is wrong: TLS 1.3+ can be negotiated only
if the client supports it, therefore it can be assumed that the client
knows that negotiating TLS 1.3+ implies being patched.

However, the first part was correct. So, "not deciding" is effectively
equivalent to deciding against approach 3 (and also against a combination
of 2 and 3), while still leaving the choice between 1 and 2 open.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 28 Nov 2009 08:41:09 +0000

Eric Rescorla wrote:
> I also share [David-Sarah] Hopwood's concern about ambiguity in the handshake

That potential weakness can be avoided by encoding the data to be added
into the hash as follows:

   struct {
       enum { fake_finished(20) } fake_handshake_type;
       enum { zero(0), (2^24-1) } fake_length;
       opaque previous_client_verify_data<12..255>;
       opaque previous_server_verify_data<12..255>;
   } PreviousVerifyData;

This works because the bytes {20, 0, 0, 0} encode a zero-length
Finished message, which if they actually appeared on the wire as
a handshake message sent in either direction, would cause the
recipient to abort the handshake. (This is similar to what Martin
suggested in a recent post. Since any fake_length that is not a
valid length for verify_data will work, we might as well use 0.)

Note that for the receiver of the extra data to fail to abort the
handshake in that case, it would have to make two independent errors,
both violating 'MUST' requirements present since SSLv3: it would have
to accept the empty Finished message out-of-order [*], *and* not
check that the contents of that message is a correct verify_data hash.

I'm completely satisfied that this approach solves the problem I was
concerned about.

> me that this approach isn't at all easy to reason about.

What matters is whether we have a solution that is easy to reason about
(and to implement and specify) once it has been proposed, not how many
posts to a mailing list were needed to get there.

----
[*] <http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt>

#  The handshake protocol messages are presented in the order they must
#  be sent; sending handshake messages in an unexpected order results
#  in a fatal error.

TLS 1.0 (RFC 2246)

#  The handshake protocol messages are presented below in the order they
#  must be sent; sending handshake messages in an unexpected order
#  results in a fatal error. Unneeded handshake messages can be omitted,
#  however. Note one exception to the ordering: the Certificate message
#  is used twice in the handshake (from server to client, then from
#  client to server), but described only in its first position. The one
#  message which is not bound by these ordering rules in the Hello
#  Request message, which can be sent at any time, but which should be
#  ignored by the client if it arrives in the middle of a handshake.

TLS 1.1 (RFC 4346)
   same wording but with "must" -> "MUST".

TLS 1.2 (RFC 5246)
   same wording but also with "should" -> "SHOULD".

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 28 Nov 2009 11:33:06 -0800

>        opaque previous_server_verify_data<12..255>;

I like the direction this is going, but think that using a length of
zero doesn't quite patch the potential weakness.  So instead of zero,
why not use 0xFFFFFF?  An attack would require that a 16MB Finished
message be ignored.

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 29 Nov 2009 00:33:26 +0000

Michael D'Errico wrote:
>>> I also share [David-Sarah] Hopwood's concern about ambiguity in the
>>> handshake hashes stream created by having data which is not properly
>>> formatted injected into the hash
> zero doesn't quite patch the potential weakness.

It does: as I said, for an implementation to be vulnerable it would
have to violate two existing 'MUST's -- failing to abort the handshake
on an out-of-order handshake message, and failing to check the correctness
of the verify_data in a Finished message. If it gets the latter wrong,
then it's clearly insecure anyway. What is sent after the fake Finished
message doesn't matter for avoiding this weakness.

(Since the previous_{client,server}_verify_data are variable-length,
I chose to encode their length explicitly, but that's a separate issue.)

> So instead of zero, why not use 0xFFFFFF?

That would work as well, but only for the same reason, i.e. that
0xFFFFFF is not a valid length for the content of a correct Finished
message.

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 28 Nov 2009 20:43:36 -0800

> message doesn't matter for avoiding this weakness.

The theoretical weakness, as I understand it, is that inserting the previous
verify_data directly into the handshake message stream would allow an
attacker to send the previous data to an unpatched peer at the point where
it would get inserted by a patched peer.  If (and it's a big if) that peer
ignores that data, then the handshake has the possibility of completing.

Your fix is to insert a "fake" header in front of the verify_data to make
the attack impossible.  The problem with using a zero length is that the
4-byte header you inserted is a _valid zero-length Finished message_.  If
you believe that the theoretical attack can work, then you have to also
believe that it's possible for that broken peer to ignore a zero-length
Finished message.

Using any length that is longer than the inserted data should completely
plug this hole.

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 29 Nov 2009 05:25:00 +0000

[...]
>> on an out-of-order handshake message, and failing to check the
>> correctness of the verify_data in a Finished message. If it gets the
>> latter wrong, then it's clearly insecure anyway. What is sent after
>> the fake Finished message doesn't matter for avoiding this weakness.
> 
> The theoretical weakness, as I understand it, is that inserting the
> previous verify_data directly into the handshake message stream would
> allow an attacker to send the previous data to an unpatched peer at the
> point where it would get inserted by a patched peer.  If (and it's a
> big if) that peer ignores that data, then the handshake has the possibility
> of completing.

The problem was that it wasn't possible to infer from the spec that
any possible extra handshake message at that point would cause an abort.
For the Finished message, it is possible to infer that it will.

> 4-byte header you inserted is a _valid zero-length Finished message_.

No, a valid Finished message would have to include a verify_data hash
(36 bytes in SSLv3; 12 bytes or more in TLS). It isn't plausible to
suppose that an implementation that is secure in other respects would
just ignore an extra Finished message of the wrong length and not
containing the right hash.

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 29 Nov 2009 11:12:37 +0100

On Nov 28, 2009, at 9:41 AM, David-Sarah Hopwood wrote:

>> handshake

Arguably a single receiver-side bug might be enough -- namely, having  
a receiver *ignore* out-of-sequence messages without looking at their  
content.  Then if an adversary includes the above in the actual  
handshake data sent to one of the peers, the receiver would interpret  
the concatenation previous_client_verify_data ||  
previous_server_verify_data as one or more additional handshake  
messages, might similarly ignore these as unexpected, and with a non- 
negligible probability would end up at the correct message boundary to  
parse the next actual handshake message.

(Encoding the actual combined length of the previous_..._verify_data  
fields seems simpler to analyze -- this still wouldn't be a valid  
Finished message; or hash an empty Finished first, then a pseudo- 
message containing the previous verify data.  Of course, neither of  
this avoids the potential problem with buggy receivers that ignore out- 
of-sequence messages.  That pseudo-message *could* use the Certificate  
type to maximize the probability that buggy implementations will look  
at it and stop [given that Certificate is expected at that point of  
the protocol], but I guess that looks even weirder.)

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 29 Nov 2009 11:23:23 +0100

>>>>> renegotiation attack, and making it the standard Finished  
>>>>> calculation
>>>>> for

>>> that
>>> that

Yes.  That's exactly what I meant:

The arguments against approach 3 don't imply that we should be using  
approach 1 -- but only the TLS 1.3 specification will really have to  
decide between approach 1 and approach 2.

Bodo

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 29 Nov 2009 09:03:26 -0800

> containing the right hash.

I meant "well-formed", not valid, sorry.  It is plausible to think that
a peer might ignore an empty Finished message, if you believe it can be
broken in the way that would allow the theoretical attack to succeed.

Making the "fake_length" extend beyond the end of the PreviousVerifyData
completely solves this since it would cause the peer to read parts of
the subsequent valid messages into the fake Finished message.  Thus the
Certificate message would be lost, making it impossible for the handshake
to succeed.

And if that doesn't convince you, would you agree that changing the length
wouldn't hurt anything?  If so, then you can appease me by making it
0xFFFFFF instead of zero.

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 29 Nov 2009 09:10:14 -0800

Bodo Moeller wrote:
> Finished message; or hash an empty Finished first, then a pseudo-message 
> containing the previous verify data.  Of course, neither of this avoids 
> the potential problem with buggy receivers that ignore out-of-sequence 
> messages.  That pseudo-message *could* use the Certificate type to 
> maximize the probability that buggy implementations will look at it and 
> stop [given that Certificate is expected at that point of the protocol], 
> but I guess that looks even weirder.)

Encoding a longer length is even better since that will suck some of the
real Certificate message into the fake Finished message, making it
impossible for the handshake to complete.  How much longer?  Why not just
use the maximum length of 0xFFFFFF?

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 29 Nov 2009 22:06:14 +0000

> 0xFFFFFF instead of zero.

I have no problem with this. By all means make it 0xFFFFFF.

---

From: Marsh Ray <[email-masked]>
Date: Sun, 29 Nov 2009 18:14:29 -0600

> The real security advantage of implicit is that you know that the opponent

I agree that is possibly an advantage, but a very weak advantage.

> you don't know if the opponent just blindly accepted what you sent without

By that logic, how do you know that he's checking the Finished message hash?

- Marsh

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Nov 2009 08:11:07 +0100

> I agree that is possibly an advantage, but a very weak advantage.

Well, It's not weak or strong in a cryptographic sense. The weakness is
totally dependent on whether implementers get this right or not. The problem
is that you can't tell whether they did since it doesn't show.
If they get it right, there is no weakness, if some or any get it wrong, it
may significantly reduce the value of this effort.

With implicit, implementers can't get it wrong and still produce a valid
finished message.

I personally think this is a significant advantage.

> By that logic, how do you know that he's checking the Finished message hash?

That you never know, but he wouldn't be able to produce a valid Finished
message unless he derived the accurate data from the previous handshake.

/Stefan

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Nov 2009 09:55:17 +0200

> I personally think this is a significant advantage.

+1