Subject: [TLS] draft-ietf-tls-renegotation: next steps

From: <[email-masked]>
Date: Wed, 16 Dec 2009 10:53:37 +0100

(wearing IETF Security Area Director hat)

First of all, I want to say that it's clear that this was an unusual
IETF Last Call -- and this was expected, too. Usually a WG document
does not go to IETF Last Call until everyone in the WG is happy with
it, so most of the time, very little happens during the last call.

However, this document addresses an urgent security vulnerability, so
as discussed in the Hiroshima TLS WG meeting, it was decided to
solicit comments from the TLS WG members and the wider community
partly overlapping.

This means we've gotten quite a few emails. However, although the
volume of emails was large, I was a positively surprised how little
disagreement there was.

There was basically no disagreement about the functionality (what the
spec should do); only about how exactly the functionality should be
implemented.  And even there, most people agreed on most of the big
issues, and the disagreement was mostly about details that, frankly
speaking, are not all that important (especially to the users of TLS).

Some have even dismissed many of the comments as "aesthetic".  
I disagree with that -- the discussions were not that different from
ordinary discussions in any IETF WG. However, I think it's fair to say
that most comments were more about "it could/should be better" than
"it won't work". Also, despite the occasionally heated email
exchanges, I believe most people agree that getting this security
vulnerability fixed quickly is more important than the specific
details (as long as the details are not totally unreasonable).

Summarizing some open issues:

- We seem to have rough consensus that both clients and servers need
to be able, if they choose to do so, fully operate with legacy
(unpatched) systems, at least for a limited period of time (despite
the security implications). This implies the need for some form of
"signaling" in both directions, where a patched system can determine
if the other end supports the fixed renegotiation or not.
(The current draft supports this.)

- We seem to have rough consensus that the specification should
include some form of C->S signaling that can be used with
extension-intolerant servers and/or SSLv2 compatible client hellos.
(The current draft has the "magic cipher suite value" for this
purpose.)

- For S->C signaling, we seem to have rough consensus for a TLS
extension in ServerHello.

- Whether verify_data should be sent over-the-wire or not: current
text (send it over-the-wire) seems to have more support (at least 2/3
vs. 1/3).  While the rough consensus is perhaps a bit rougher than
we'd normally hope to see, I believe most participants (of either
opinion) would prefer making a decision over continuing the discussion
until some indeterminate time. So we pick the one with more support.

- Whether to prohibit sending the extension (in initial ClientHello),
or require the magic cipher suite even if the extension is sent (in
initial ClientHello): The consensus is again a bit rougher than we'd
normally hope to see, but the current text (either is allowed) has
more support (about 2/3 vs. 1/3), so we keep it. And again, I believe
most participants prefer make some decision over continuing the
discussion.

- There was some discussion on whether to add the magic cipher suite
to patched renegotiation ClientHellos (in addition to the extension),
too. I believe rough consensus is not to do this.

- The current draft doesn't clearly say what should be included in
legacy (insecure) renegotiation ClientHellos. I am not sure if we have
enough clear opinions to call consensus, but keeping it aligned with
the initial ClientHello (either MSCV or extension) seems to be one
simple approach (but I hope to see the actual text).

- Yngve Pettersen proposed explicitly saying that servers that
implement this draft must be extension-tolerant (not break if the
client sends extensions) and version-tolerant (not break if the client
proposes a higher version number than the server supports).  It seems
these are not new requirements, so this would be an editorial
clarification (but being very clear doesn't hurt).

- Yngve also proposed adding requirements/recommendations about
fall-back/reconnection procedures (to extension-less handshake, or
earlier versions). I think the rough consensus is that the document
should not mandate or even recommend anything about such
fall-back/reconnection procedures (which are mostly not related to
renegotiation anyway).

- There was discussion about adding another C->S signaling method
using the proposed version: if proposed version >= 1.3, and the
negotiated version is <= 1.2, it means the client supports this draft
(what happens if negotiated version is >= 1.3 would be specified in
the TLS 1.3 spec). This would allow TLS >=1.3 clients to remove other
signaling (magic cipher suite/extension) from initial ClientHellos
(but requires extra code in the server). As Tom Petch (and others)
noted, if we want to do this, it has to be done now (and can't be done
when doing TLS 1.3). There was relatively little support for doing
this, and rough consensus seems to keep the spec as is in this regard.

- There were some proposals to make the ordering of extensions (in
either ClientHello, ServerHello, or both) significant somehow.  The
rough consensus seems to keep the list unordered.

- There was a proposal to change the exact contents of the server's
extension. There wasn't much support for this, and rough consensus
seems to keep them as-is.

- There have been some concerns about the clarity of the
specification.  I think there's some room for improvement here -- I
will work with the editor and WG chair to do something about this.

I've asked the document editor to update the draft as soon as
possible. The IESG will discuss this document this Thursday (December
17), and I hope we can have an approved specification before
Christmas.

I realize that not everyone will be happy with these decisions, but in
my judgment as Security Area Director, the choices are in line with
the rough community opinion, and are technically reasonable (many
other choices would have been reasonable, too). In particular, I
believe that continuing these discussions until some indeterminate
time in 2010 would not be in the best interest of the community (many
of whom have expressed that they prefer an OK solution this year,
instead of possibly-slightly-improved one next year).

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Dec 2009 16:05:49 +0100 (MET)

> most participants prefer make some decision over continuing the

I'm sorry for creating a confusion and dispute about this.
Allowing the sending of an empty extension RI on initial ClientHello
should not be a problem and I would find a MAY perfectly acceptable.

The real important thing is, that the inclusion of the MCSV is
a MUST, because it will reduce the procotol complexity and robustness
and allow absolutely _every_ implementer to save code.

> too. I believe rough consensus is not to do this.

I have a VERY strong objection to leave out the MCSV from any
ClientHellos.  It will save everyone code if we mandate the
use of MCSV on all ClientHellos including secure renegotiation
ClientHellos, and it will make the protocol *MUCH* more foolproof.

> simple approach (but I hope to see the actual text).

Again, the choice is obvious: MCSV, *NO* extension.

Anything else just makes no sense and may obviously cause interop
problems for some backwards interop scenarios, because it is
a backwards-incompatible change.

About the backwards interop scenarios in general:

Can we please discontine the misleading terminology "lenient client/server"
and instead refer to the specific backwards interop scenarios that
we address with a recommendation?

(1)  updated client allowing initial handshakes with old servers
(2)  updated client allowing renegotiation handshakes with old servers
(3)  updated server allowing initial handshakes with old clients
(4)  updated server allowing renegotiation handshakes with old clients

As i previously mentioned, I think that we want to get rid of
(4) as fast as we can (SHOULD NOT), hope to get rid of (2)
at the end of the transition period (MAY), and leave (1) and (3)
completely to the consumers of the technology.

I'm strongly opposed to any suggestions to impair (1) or (3) in
the solution we ship.

> instead of possibly-slightly-improved one next year).

I do not agree to your determination of rough consensus.

rfc4677, 5.2 Getting Things Done in a Working Group

   Another aspect of Working Groups that confounds many people is the
   fact that there is no formal voting.  The general rule on disputed
   topics is that the Working Group has to come to "rough consensus",
   meaning that a very large majority of those who care must agree.

   The lack of formal voting has caused some very long delays for some
   proposals, but most IETF participants who have witnessed rough
   consensus after acrimonious debates feel that the delays often result
   in better protocols.  (And, if you think about it, how could you have
   "voting" in a group that anyone can join, and when it's impossible to
   count the participants?)  Rough consensus has been defined in many
   ways; a simple version is that it means that strongly held objections
   must be debated until most people are satisfied that these objections
   are wrong.

It just doesn't feel right if some peoples feelings about aesthetics
are considered more important than other peoples technical issues.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Dec 2009 08:22:35 -0800

>I do not agree to your determination of rough consensus.

Are you saying that in general, or are you saying you intend to appeal the decision? The two are quite different.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 16 Dec 2009 08:55:05 -0800

> most participants prefer make some decision over continuing the

There is no need to prohibit sending an empty RI in an initial Client
Hello.  Would a server be required to abort if it received it?  That
doesn't seem like a good design.

I've implemented RI + MCSV and the logic I used was to have a boolean
for whether the peer is patched, plus a string to hold the received
renegotiation_info.  When a ClientHello is being processed, the flag
is set to false and the string is cleared.  Then if the MCSV is seen
in the cipher suite list, the flag is set to true.  Then when parsing
the extensions, if RI is encountered, the flag is set to true and the
renegotiation_info is extracted into the string.  There is no need to
have special cases for initial vs. renegotiation handshakes.

> too. I believe rough consensus is not to do this.

There is no need to prohibit sending the MCSV in a renegotiation Client
Hello.  Using the same logic above, all that it does is flip a bit in
the server's state.  If the client believes it is doing a renegotiation,
then it will also send RI with verify_data, which will get processed as
above.

> this, and rough consensus seems to keep the spec as is in this regard.

As a practical matter, any TLS 1.3 code will need to still send RI and
MCSV since it will surely encounter older servers for a long while
after that spec gets published.  So it seems that this is unnecessary.

Mike

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Dec 2009 17:57:03 +0100 (MET)

Paul Hoffman wrote:
> Are you saying that in general, or are you saying you intend
> to appeal the decision? The two are quite different.

I believe this still captures my position adquately:

http://www.ietf.org/mail-archive/web/tls/current/msg05260.html

I do not think there has been a satisfactory decision
about the semantics of MCSV.   Regrettably, I have added to the
confusion myself. by asking for overly strict semantics.

Without a specific proposal, I do not even see a base to
determine consensus, much less for an appeal.

One possible semantic that would address my technical issues
would be along these lines:

   All conforming Clients MUST include the cipher suite value
   TLS_RENEGO_PROTECTION_REQUEST in the cipher_suites list of _every_
   ClientHello handshake message they send.  This includes clients that
   do not implement renegotiation or have it disabled.  This cipher
   suite value MAY appear anywhere in the cipher_suites list.

   Conforming clients that compose an initial ClientHello handshake
   messages with other TLS extensions, MAY additionally include
   an empty TLS extension "renegotiation_info".

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 Dec 2009 12:42:08 -0600

>    an empty TLS extension "renegotiation_info".

Current wording http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01
>    TLS clients which support this draft MUST generate either the
>    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
>    cipher suite with every ClientHello.

I expect it will be reiterated in the next revision.

How does this not address the fundamental issue?

(Other than it doesn't provide assistance to an implementation which
chooses to conduct an insecure negotiation and subsequent insecure
renegotiation with an old unpatched extensions-intolerant server).

And if not, does anyone propose wording that substantially improves it
without changing the current cryptographic computations (e.g., the PRF
inputs)?

Short and to the point please!

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Dec 2009 11:08:10 -0800

> simple approach (but I hope to see the actual text).

Attached is some candidate text that attempts to implement this. 

  It is possible that un-upgraded servers will request that the client
  renegotiate.  It is RECOMMENDED that clients refuse this
  renegotiation request.  Clients which do so MUST respond to such
  requests with a "no_renegotiation" alert [RFC 5246 requires this
  alert to be at the "warning" level.]  It is possible that the
  apparently un-upgraded server is in fact an attacker who is then
  allowing the client to renegotiate with a different, legitimate,
  upgraded server.  In order to detect this attack, clients which
  choose to renegotiate MUST provide either the
  TLS_RENEGO_PROTECTION_REQUEST SCSV or "renegotiation_info" in their
  ClientHello.  In a legitimate renegotiation with an un-upgraded
  server, either of these signals will be ignored by the server.
  However, if the server (incorrectly) fails to ignore extensions,
  sending the "renegotiation_info" extension may cause a handshake
  failure.  Thus, it is permitted, though NOT RECOMMENDED, for the
  client to simply send the SCSV.  This is the only situation in which
  clients are permitted to not send the "renegotiation_info" extension
  in a ClientHello which is used for renegotiation.

  Note that in the case of this downgrade attack attack above, if this
  is the initial handshake from the server's perspective, then use of
  the SCSV from the client precludes detection of this attack by the
  server.  However, the attack will be detected by the client when the
  server sends an empty "renegotiation_info" extension and the client
  is expecting one containing the previous verify data.  By contrast,
  if the client sends the "renegotiation_info" extension, then the
  server will immediately detect the attack.

After flip-flopping on this in my head a few times, however, my
personal view, is that I think this goes too far in the direction of
accomodating broken servers. Sending RI in this instance only creates
an interop problem when a server (1) is doing something we know to be
really unsafe and (2) can't even ignore extensions correctly. We've
seen a number of suggestions that we actually forbid renegotiation in
case (1) and while I suspect WG consensus doesn't go that far, it's not
clear to me that we need to not only allow it but also compensate for
servers which are broken in other respects. So, my preference would
be to simply mandate RI with the previous verify_data here as in
all other cases.

> 17), and I hope we can have an approved specification before

I'm working on revisions now.

-Ekr

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 16 Dec 2009 15:00:39 -0500

Martin's text contradicts the AD's decision ...

> too. I believe rough consensus is not to do this.

In addition, the logic of not permitting RI unless some other extension
is used is dubious.  A client with no need to cater to servers that are
both broken and unpatched should not be forced to gin up some other
extension just so it will be allowed to send an empty RI.

>    cipher suite with every ClientHello.

... with possible addition of "or both" just to be perfectly clear that
"either" means or, not exclusive-or.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marsh Ray
Sent: Wednesday, December 16, 2009 1:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: [POSSIBLE SPAM] Re: [TLS] draft-ietf-tls-renegotation: next
steps
Importance: Low

>    an empty TLS extension "renegotiation_info".

Current wording
http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01

- Marsh

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

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 Dec 2009 14:08:40 -0600

Eric Rescorla wrote:
>   failure.

> Thus, it is permitted, though NOT RECOMMENDED, for the

This is bad because it greatly complicates the simple definition of the
SCSV as "exactly the same semantics as an empty 'renegotiation_info'
extension". In fact, it tends to convey exactly the message that the
attacker wants "this is an initial handshake".

>   is expecting one containing the previous verify data.

It doesn't seem very robust to me. A very long chain of things have to
go just so (some even at the option of the attacker) for the client to
detect this attack.

> By contrast,
> After flip-flopping on this in my head a few times,

You're not the only one. :-)

> however, my
> accomodating broken servers.

Not so much that we want to specifically not be accommodating, but this
case introduces complexities and internal contradictions at the expense
of non-crusty clients and servers.

There's also something to be said for specifically declining to
accommodate things in a spec that are already broken twice or thrice
over (depending on which spec you read) in the first place.

It's not even fixing things half-way. It may be fixing things
one-third-way or not at all depending on your philosophy.

IMHO, the IETF shouldn't endorse the making of insecure TLS connections
by attempting to secure them poorly.

In this case, however, the specs should leave enough room for
applications to do that sort of thing on their own if they so choose.
But in doing so, application vendors, admins, and users alike should
know that they are engaging in risky behavior in public. It's visible on
the wire.

> Sending RI in this instance only creates
> servers which are broken in other respects.

> So, my preference would

+1 for simplicity and consistency

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Dec 2009 21:32:35 +0100 (MET)

First, we need to fix the Definition of the TLS_RENEGO_PROTECTION_REQUEST:

This cipher suite value is the Client to Server signal that the client
is updated and asks to apply the strict rules of secure renegotiation
applied to the current handshake -- no excuses.

If SCSV is received by a server on an initial handshake that does
not contain a renegotiation_info TLS extension, then the server
should apply the same semantics as if it had received an empty
TLS extension RI in that ClientHello.

Concerning the question what a client should send on a backwards
interoperable renegotiation handshake:

The rule is "if you can't be good, at least be good at it.".

That means if the clients configuration permits old-style renegotiation,
then he should NOT try fancy new tricks with that old server on the
renegotiation handshake that he didn't do on the initial handshake.

i.e. if the client had sent TLS extensions on the initial handshake,
there is no problem with _sending_ TLS extension RI on the renegotiation
handshake with the old server.

However, if the client did _not_ use TLS extensions (but SCSV) on
the initial handshake with an old server, then there are only
to sensible options for the client on renegotiation:
  (a) abort when the client doesn't allow old-style renegotiation
  (b) send an extension-less ClientHello with MCSV on renegotiation.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Dec 2009 21:59:07 +0100 (MET)

> Martin's text contradicts the AD's decision ...

I do not fully agree with the AD's determination of rough consensus.

For the MCSV signaling, the real rough consensus is different from
what Pasi wrote:

http://www.ietf.org/mail-archive/web/tls/current/msg05306.html

A mandatory Client->Server signaling through cipher suite may
have less fanatic followers by the count of numbers, but technical
advantages and _no_ technical objections have been raised against it.

The current either cipher suite or empty TLS extension RI signaling
may have more "pro", but has significant objections against it
because of the ambiguity, increased complexity, a 4x code size
burden for old non-rengotiating servers and additional testing
complexity.

So as far as rough consensus is concerned, it is definitely
with the approach I described.  This is what the IETF procedures
are about.  Otherwise we could just go back to counting votes.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 Dec 2009 16:09:02 -0600

> http://www.ietf.org/mail-archive/web/tls/current/msg05306.html

That email is Michael Gray of IBM saying "I do not believe a technical
objection to the CipherSuite method has been presented" which is not
remotely the same as a real lack of "rough consensus".

> have less fanatic followers by the count of numbers,

Fanaticism is orthogonal to cardinality.

> but technical

Let me re-state them then.

Making SCSV mandatory means that it no longer is the equivalent of an
empty extension, which raises the question of exactly what it does mean.
Saying it means "I'm updated" is simply begging the question.

Sending SCSV with no extension in a renegotiation Hello is a very
questionable thing to do. That combination of values is needed for
clients that wish to send an _initial_ hello and interoperate with
extensions-intolerant servers! Overloading to also mean (and be
ambiguous) with "I'm intentionally _renegotiating_ in a manner known to
be insecure" is bad. And that is a technical objection.

> because of the ambiguity,

"MUST send this and/or that" is not an ambiguity and you know it.

> increased complexity,

I disagree, see below.

> a 4x code size
> burden for old non-rengotiating servers

How can a TLS client prove in advance that the server could not have
been enticed to renegotiate by a MitM? It is not possible to do in
general, and thus no general implementation of the protocol can rely on
it for security.

I just don't see any explanation other than you are pushing this to save
a few lines of code in your own particular circumstance.

> and additional testing

Yes. These additional test cases are unfortunate, but nearly all vendors
agreed that it was necessary to have an SCSV option to avoid hitting
slow failures connecting to the extensions intolerant servers seen in
the wild.

If you were so concerned with testing complexity you wouldn't be pushing
to make simplifying assumptions in your implementation. Testing all
cases is certainly more work than the minimal code to support the one
and/or requirement.

> with the approach I described.

The "mandatory SCSV" scheme seems primarily useful if your solution
works by modifying the PRF inputs on renegotiation and letting the
Finished hash comparisons detect the attack. That method had some merit
and was given serious consideration by myself and many others.

But again, the reason I could not ultimately support it is because it
involved changing the cryptographic calculations. Regardless of whether
you or I think that it was done correctly, it is a very very big deal to
some important users. It will invoke a formal cryptographic review
process which will prevent this solution from being usable by many
important sites any time soon.

Retro-fitting a "mandatory SCSV" requirement to the RI extension
proposal is what introduces the complexity and ambiguity without a
well-defined benefit.

Here are all the things that have to happen in order for a mandatory
SCSV requirement to be of benefit:

1. Client has to be in compatible/insecure mode.
2. Mitm has to impersonate a server of interest to the client.
3. Client does not check Mitm's cert on the initial handshake.
4. Client must be willing to conduct a server-initiated renegotiation
(from anonymous server).
5. Legit target server has to be in compatible/insecure mode.

If all these things happen, then the complicated protocol change
prevents one attack variant but leaves others.

In addition, another necessary condition for this to actually be a
useful improvement is:

6. Mitm can find no unpatched server of equal or greater value with
which to attack the connection of this client.

The additional complexity and ambiguity that the "mandatory SCSV" scheme
introduces for no real benefit is my technical objection against it.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Dec 2009 16:12:35 -0600

> are about.  Otherwise we could just go back to counting votes.

Counting votes is problematic in an open membership organization.  Rough
consensus determination is a fairly subjective operation.  I.e., there's
going to be unhappy people no matter what.  But rough consensus is much
better than elections.

IMO we need a process for dealing with vulnerabilities in protocol
specifications.  Such a process should encourage disclosure to the IAB
and IESG, including permission for them to manage further disclosures to
other IETF participants, all so as to ensure private discussion of fixes
that approximates open discussions and avoids surprising the community
with faits accompli or nearly accompli.  (Regardless of what one thinks
happened in this case, handling of future cases like this one could be
horrible without such rules.)

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Dec 2009 23:33:36 +0100 (MET)

> remotely the same as a real lack of "rough consensus".

you got this wrong.  It shows that up to date at least 3 independent
people have not noticed that anyone has raised a technical issue
against a mandatory SCSV.  This particular semantics has always
been part of my proposal.

> empty extension, which raises the question of exactly what it does mean.

http://www.ietf.org/mail-archive/web/tls/current/msg05372.html

> questionable thing to do.

Nope.  The purpose of that cipher suite value, which EKR has cloned
from my I-D (including its name), has always been defined as a
simple signal Client->Server "Hi, I'm updated", and is meant to
imply that an updated server should apply the strict rules of
secure renegotiation.

> be insecure" is bad. And that is a technical objection.

Now you're trying to make something up in a haste.

I'm wondering which vendors are this that have already shipped
an implementation based on the original TLS extension RI proposal
and are now trying hard to prevent any changes to the document
that would require them to patch again.

You are aware that the wording that I proposed does _not_ say
that sending a TLS extension RI as the only extension would
not be allowed.  It is allowed, its up to the vendor.

Yes, it would happen that some updated clients send only SCSV and
expect the server to understand that.  I don't think that is a problem.
That update would be with much less time pressure, and then I was
assured so many times that sending extensions was so standard and
just everybody was doing it already, that I can not believe this
to become an unsurmountable problem for early adopters.

> general, and thus no general implementation of the protocol can rely on

I'm sorry, I have no idea what you're talking about.

Fixing security problems is not about fixing particular attack scenarios.
it is about fixing the defect in the underlying architecture.

If there is a unique and uncoditional signal from the client in
every ClientHello handshake message that the client is updated
and requests the handshake to be performed according to the strict
rules of secure renegotiation, then it will be completely impossible
for an attacker, independent of any attack scenarios, to make an
updated client perform an old handshake with an updated server.

That is what fixing the vulnerability at an abstract level is about,
and makes the architecture so much simpler and robust, because you do
not have to distinguish scenarios.  And it is also completely independent
of which peer allows which kind of backwards interop.

> a few lines of code in your own particular circumstance.

Everyone can save those lines!  you can remove a lot of conditionals
in the code.

> and was given serious consideration by myself and many others.

No, it is universally useful, and saves everyone code and test complexity.

> introduces for no real benefit is my technical objection against it.

It just doesn't apply and ist _MUCH_ to complicated for a simple
design, anyway.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Dec 2009 23:49:07 +0100 (MET)

> to become an unsurmountable problem for early adopters.

I got confused.  It is about early adopter clients that send
TLS extension RI (not knowning about SCSV) and might run into
updated servers that look only for SCSV.  But as I described,
these are going to be servers that do not renegotiate anyway,
so there even is _no_ security problem involved.  Those
that implement secure renegotiation will always have to be able to
recognize a TLS extension in ClientHello.

So really, making up an argument against a mandatory SCSV
is going to be tough.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 Dec 2009 17:18:21 -0600

>> that would require them to patch again.

I don't know of any vendors that have "shipped" an implementation. The
closest I know of is OpenSSL has something in their source control
system but doubt they would have any problems with whatever changes.

Implementing the proposed fix is just not that hard, compared to the
difficulty of analyzing the proposals from all angles.

> updated servers that look only for SCSV.

Such servers are not permitted by the current proposal.

>From http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt
>    Upon receipt of the "renegotiation_info" extension, both client and
>    server implementations which support the extension MUST verify that
>    it contains the correct contents as specified above (the previous
>    client Finished.verify_data in the ClientHello and the concatenation
>    of both Finished.verify_data values in the ServerHello).  If the
>    contents are incorrect, then it MUST generate a fatal
>    "handshake_failure" alert and terminate the connection.
[...]
>    TLS servers MUST support both the "renegotiation_info" extension and
>    the TLS_RENEGO_PROTECTION_REQUEST SCSV.  TLS servers which support

> But as I described,

TLS does not define such a thing as a "server that does not
renegotiate". There may be in fact some application protocols or servers
which do not, but TLS provide no way to indicate this in the handshake.

In practice, it requires deep code inspection to prove and many
application authors have been surprised to find out that their TLS
implementation will renegotiate for them automatically.

Therefore, it is impossible for a general-purpose client to know this
about any specific server.

Therefore, it is a useless consideration for the protocol design.

> so there even is _no_ security problem involved.

An unpatched TLS connection can only be believed secure with code
inspection done on _both_ endpoints to prove that renegotiation can
never happen and/or application protocol analysis. Since a primary
feature of TLS is to support interoperability between diverse client and
server implementations, this is just not a common enough case to be
worth considering.

The fact that you are confident that some of your systems are
implemented that way is just not a useful consideration in developing a
solution for the general case.

> Those

Yes, you will need to be able to recognize one particular extension in
order to support the fix for renegotiation.

I've proven that that basic code for this can be written in less than an
hour, with some test cases. Some organizations may take slightly longer.
Organizations which cannot handle that degree of complexity should not
IMHO be implementing security protocols.

> So really, making up an argument against a mandatory SCSV

Not really.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Dec 2009 01:28:52 +0100 (MET)

> >    the TLS_RENEGO_PROTECTION_REQUEST SCSV.  TLS servers which support

You're quoting section 3 of the document.

That part only applies to TLS peers implementing secure _renegotiation_.

Section 4 seems to be incomplete, the last paragraph describes
the situation only for non-renegotiating clients, the paragraph
for non-renegotiating appears to be missing from section 4,
but belongs there as well and with comparable characteristics
than for non-renegotiating clients.

> implementation will renegotiate for them automatically.

An SSLv3 or TLS implementation will definitely not perform
TLS renegotiation by accident or coincidence.  It will require
a few lines of code to enable that.

What may happen, is that developers or maintainers who inherited
code are not (or no longer) aware of the functionality being present.

> Therefore, it is a useless consideration for the protocol design.

Huh?

> server implementations, this is just not a common enough case to be

Code inspection?  That seems to be a fairly inefficient way.

If you want to know whether it is there, try it.
If you want to reliably disable it, it's <10 LoC.

I'm sure the OpenSSL code maintainers didn't need a code inspection
in order to find out which statements would be necessary to
make sure the renegotiation will _not_ work.

> > So really, making up an argument against a mandatory SCSV

I'm all ears.  Go ahead.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 17 Dec 2009 03:10:25 +0000

Eric Rescorla wrote:
>   server.

That is not correct. If the server is also upgraded, it can detect that
the SCSV has been sent without the extension on a renegotiating handshake.
This case must be an attack, because the client wouldn't have sent only
the SCSV if it knew that the server was upgraded. (If the connection is
a legitimate renegotiation and the server hasn't changed, the client
would know that it is upgraded from the presence of the extension in
the ServerHello of the previous handshake.)

It is only un-upgraded servers that will not detect the attack (but
the client accepted that possibility, contrary to the RECOMMENDATION
in the second sentence of the above text).

OTOH, I think it's perfectly reasonable not to allow clients to send
only the SCSV on a renegotiation. As you say,

> really unsafe and (2) can't even ignore extensions correctly.

Either way, the draft should specify that an upgraded server MUST abort
a renegotiating handshake if it receives only SCSV without the extension.

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

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 17 Dec 2009 03:19:00 +0000

Martin Rex wrote:
>   (b) send an extension-less ClientHello with [S]CSV on renegotiation.

(b) is only secure if an upgraded server MUST abort if it receives an
SCSV without an extension on a renegotiating handshake.

I am *strongly* opposed to (b) without that requirement. With that
requirement, I'm still weakly opposed to your argument here. Always
sending the extension in a renegotiating ClientHello is much simpler.

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Dec 2009 04:39:21 +0100 (MET)

David-Sarah Hopwood wrote:
> I am *strongly* opposed to (b) without that requirement.

That is what I tried to describe in the second sentence above of 
the mail that you quoted: "apply the strict rules of secure renegotiation
to the current handshake -- no excuses".  You're welcome to use
more appropriate words to describe this.

> 
> With that requirement, I'm still weakly opposed to your argument here.
> Always sending the extension in a renegotiating ClientHello is much
> simpler.

That is one of the few useful conditionals, because it would be
backwards-incompatible and unreasonable action to send an extension
on a backwards-interop renegotiation scenario with an old(!) server
if _NO_ extension was sent on the initial handshake.

The spec should _not_ require implementers to offer this, and neither
require apps to enable this, but _IF_ they offer it, then it just
doesn't make sense to offer backwards interop renegotiation in an
inconsistent fashion.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 17 Dec 2009 00:10:29 -0600

> You're quoting section 3 of the document.

You mean the section "3.  Extension Definition"?

> That part only applies to TLS peers implementing secure _renegotiation_.

Whatever gave you that idea?

Obviously the part that says
> If this is the initial handshake for a connection, then the
>       "renegotiated_connection" field is of zero length in both the
>       ClientHello and the ServerHello.
is not limiting itself to renegotiations.

I don't know how the IETF rules work, if a future implementaion can say
it implements proper TLS without implementing this extension. In
practice, every TLS implementation (except perhaps yours) is going to
want to implement the security fix properly lest they be shunned by
other implementations.

> for non-renegotiating appears to be missing from section 4,

For non-renegotiating what? There appears to be a word missing so your
paragraph seems to be incomplete.

> than for non-renegotiating clients.

You appear to be questioning why there isn't an equivalent statement
about servers which do not renegotiate. If its absence is conspicuous
and distracting to you, perhaps we should strike that whole last
paragraph. It is redundant anyway.

It's not an equivalent situation because the server must respond to the
client hello as it was sent and can not "simply use the SCSV in all
initial handshakes" like the client can. The logic for a
non-renegotiating server does not reduce as much as it does for a
non-renegotiating client.

> a few lines of code to enable that.

Many applications have gotten renegotiation for free from their helpful
TLS implementations with zero lines of added code.

> code are not (or no longer) aware of the functionality being present.

Or even more likely, the application writers.

>> Therefore, it is a useless consideration for the protocol design.

Yes. It is impossible for a TLS clients to know that they are talking to
a server which can not be triggered to renegotiate in the general case,
or even in most specific cases.

> If you want to know whether it is there, try it.

And you will conclude wrongly and it will result in a security
vulnerability.

Try doing a client-initiated renegotiation against MS IIS for example.
It will hang up on you. Yet it's clear that a properly constructed HTTP
request and the right server configuration will cause it to perform
server-initiated renegotiation.

Similarly, an https client may refuse requests for renegotiation unless
he has a client certificate he's willing to offer to that specific
server. There is absolutely no way for a server to determine whether
this is the case or not with the client that's attempting to connect
insecurely.

It is very difficult to prove a negative.

Security analyses based on "the remote endpoint does not renegotiate
therefore our connection is not vulnerable" are betting they can prove
that negative correctly every single time. My money is on the attacker
who only needs to disprove it once.

Again, the TLS protocol does not define such a thing as "TLS without
renegotiation" and consequently there is no way for an endpoint to know
that his remote peer can never be enticed into renegotiating.

> If you want to reliably disable it, it's <10 LoC.

http://cvs.openssl.org/timeline?d=5&e=2009-Nov-10&c=2&px=&s=1&dt=1&x=1&m=1&w=0

It was a little more than 10 LoC, but not a huge amount either.

> make sure the renegotiation will _not_ work.

I guess you've never looked at the OpenSSL codebase then. But I don't
actually know of any codebase in which you can usefully change it
without a little code inspection first.

- Marsh

---

From: <[email-masked]>
Date: Thu, 17 Dec 2009 12:30:49 +0100

> advantages and _no_ technical objections have been raised against it.

Several people have very clearly and strongly objected to making the
MSCV mandatory-to-include in ClientHello. You seem to be suggesting
that their opinions don't somehow matter because they are, in *your*
opinion, not "technical".

> burden for old non-rengotiating servers and additional testing

If the specification text is ambiguous, we obviously need to fix that.

About the code/testing complexity/effort: I would say most people
believe that no matter what details get selected, this is not a
significant amount of work (so small differences in lines of code or
test cases should not signify much in making the decision).

> So as far as rough consensus is concerned, it is definitely with the
> approach I described.  

I disagree.

Best regards,
Pasi
(wearing Security Area Director hat)

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Dec 2009 16:23:24 +0100 (MET)

> want to implement the security fix properly lest they be shunned by

I'm not an IETF process wizard. but I have not knowingly come
across such a situation with IETF protocols so far.

There will likely not be TLSv1.0-2010, TLSv1.1-2010 and TLSv1.2-2010.

There will be implementations of particular RFCs, but if an
implementation says TLSv1.0, that will not _by_itself_ imply
that this includes any updates.  You will probably need to look
for the update-RFC number to be explicitly mentioned.

The point in time when a product is developed or shipped or sold
does not impact this at all.

> > for non-renegotiating servers appears to be missing from section 4,
> about servers which do not renegotiate.

Correct.  The absence of that makes that update unnecessary complex.

Myself, I don't have any of the gadgets like these:
http://www.networkwebcams.co.uk/product_info.php?products_id=855

which implement SSL.  I don't know whether they desperately need
renegotiation, but I woul not discount the possibility that they
do not need it.  I don't know how many years manufacturers provide
firmware updates for such gadgets, and how difficult it is to
update them.  But if such a thing doesn't need renegotiation,
then it might make a difference for the decision for a manufacturer
whether to develop a firmware update for a 3+ year old product,
whether there's a simple "I'm updated" signaling available.

I guess we will get accustomed to using several browsers in a year
in order to not have to unnecessarily dump a lot of equiment that
isn't really defective, but no longer interoperable with browsers
from some suppliers.  Those weenies in the IETF that ask for
interoperability in communication protocols do not have a clue
about communication _and_ security, and do not understand how
important it is that you Javascript- and ActiveContent-enabled
Browser no longer talks to this dangerous WebCam and all those
other boxes and gadgets that you bought more than two years ago.

> non-renegotiating client.

Well, it _could_ be like that, as demonstrated by my specification.

> >> renegotiate".

There are a number of things that TLS fails to define -- which is
exactly the reason why the TLS renegotiation vulnerability went
unnoticed for so long.

My copy of rfc-5246 clearly describes that there are non-renegotiating
clients and servers:

rfc5246,  Appendix D

   D.4.  Implementation Pitfalls

   Implementation experience has shown that certain parts of earlier TLS
   specifications are not easy to understand, and have been a source of
   interoperability and security problems. 

   TLS protocol issues:

    -  Do you support renegotiation, both client and server initiated?
       While renegotiation is an optional feature, supporting it is
       highly recommended.

> or even in most specific cases.

So what?

Do you think that dropping from HTTPS as it is today to HTTP
will be an improvement to the overall security of the internet,
because you _are_, in fact, suggesting this?

> It was a little more than 10 LoC, but not a huge amount either.

As I previously mentioned, the "official" patch that is currently
in openssl-0.9.8l seems a little rough, because it will freeze
the handshake when the client sends a ClientHello on an established
TLS session.

The patch that I would use to reliably abort a renegotiation handshake
would be something like

s3_srvr.c:

    case SSL3_ST_SR_CLNT_HELLO_C:
+        if (NULL != s->enc_read_ctx)
+            {
+            SSLerr( /* some adequate error code */ );
+            s3_send_alert(s,SSL_AL_FATAL,SSL_AD_HANDSHAKE_FAILURE);
+            return(-1);
+	     }
	 ...
	 ssl3_get_client_hello(s,...)

> without a little code inspection first.

No, I didn't.  That diff I posted which implements my specification
is only a wild guess an works by pure chance,  just like a lot of
those TLS protocol implementations that you know perform renegotiation
without their original _implementors_ being aware of it.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Dec 2009 18:35:59 +0100 (MET)

> does not impact this at all.

Btw. if your product implements TLSv1.0+TLSextensionRI and completely
fails to interoperate with compliant implementations of TLSv1.0 without
that update, then _YOUR_ product will be TLSv1.0-incompliant -- there
is no doubt about that!

Any kind of suggestion in the specification that updated client
and servers should completely fail interoperation with compliant
implementations without that update (i.e. also initial handshakes)
is a bad idea, and I explicitly object to that.

A specification with such a suggestion is _NOT_ an update to the
existing specs, it is an entirely new, non-interoperable protocol!

Offering applications or consumers configuration options so that
they can obtain this result is slightly different.  But as soon
as you strongly suggest to kill the entire interoperability or
configure it that way by default, you no longer have an
implementation compliant to the original protocol.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Dec 2009 19:58:16 +0100 (MET)

> which do not, but TLS provide no way to indicate this in the handshake.

As evident from rfc-5246 Appendix D. renegotiation is an optional
feature of the SSLv3/TLS protocol family and not available in all
implementations of SSLv3/TLS.

Since you are still listed as an author of the spec, I consider
your interpretation fairly authoritative for what the spec intends
to say.

--which means that there is a defect, because it does currently
_not_ specify the behaviour for non-renegotiating servers
(which you incorrectly assumed to not exist).

Please fix this defect _before_ publishing this specification.

The only reason why secure TLS renegotiation can be considered
an update to the existing installed base at all (and not a different
non-interoperable protocol), is that renegotiation has never been
a core element of SSLv3/TLS and is optional-to-implement.

Essentially, the secure renegotiation spec is deprecating the
old renegotiation and defining a new, optional, secure renegotiation.

Describing potential vulnerabilities from using backwards-interoble
renegotiation with the installed base and discouraging the use of
that old optional feature is fine.  Encouraging the use the
new optional and secure renegotiation is also no problem.
Describing security implications of old TLS peers that still
offer old renegotiation is also no problem.

Discouraging the interoperability with compliant but
not updated SSLv3->TLSv1.2 on the core protocol elements
(aka initial TLS handshake) is inacceptable, because it would
make updated TLS peers non-compliant with the original TLS spec,
which implies these peers are using a different protocol.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Dec 2009 21:22:00 +0100 (MET)

> opinion, not "technical".

Well, I'm sorry, but it seems that I have totally forgotten
the technical arguments they were making, and I seem to be unable
to find it in my Email.

Since you just did that research for the determination of rough
consensus, you may still be aware of one or the other technical
argument and I would really appreciate if you could remind me,
so that I can address them in my draft--since they likely apply
to my draft.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 17 Dec 2009 15:37:50 -0600

Martin Rex wrote:
> Since you are still listed as an author of the spec,

(Shhh...I'm hoping they don't catch on.)

> I consider

As you wish, I shall interpret this matter to the full extent of my
authority.

> _not_ specify the behaviour for non-renegotiating servers

A protocol spec that says "this is how an initial handshake is to be
done" and "this is how a renegotiating handshake works" is not defective
simply because some uses of the protocol choose not to do renegotiation.

> (which you incorrectly assumed to not exist).

I have done nothing of the sort. I am quite sure there are TLS clients
and servers which absolutely do not renegotiate. I don't think any of
the widely used general purpose implementations are in that category.

But the TLS specs don't define this in the protocol such that it can
communicated as part of the handshake which establishes the security
parameters. Therefore it is not useful in making security decisions at
the TLS level.

> Please fix this defect _before_ publishing this specification.

I don't see it, sorry.

> a core element of SSLv3/TLS and is optional-to-implement.

That doesn't make sense to me.

> old renegotiation and defining a new, optional, secure renegotiation.

Don't forget the initial handshake has new requirements, too.

> (aka initial TLS handshake) is inacceptable,

Yes, my personal and professional mission is to discourage
interoperability where such interoperability does not deliver the stated
and implied guarantees for the security of the data. Too bad if you
don't like it.

My own livelihood, as well as that of most of my friends, depends pretty
directly on the security of this protocol. I have personally recommended
enough SSL/TLS-based soultions at this point that I feel quite obligated
to work on keeping it healthy.

Nevertheless, the wording of the current spec leaves the option of
interoperating (possibly insecurely) with unpatched endpoints up to
vendors and their customers to decide. My personal recommendation is to
be in this compatible mode for as short a time as possible because it
does not offer the full security guarantees intended for TLS. And I'm
not letting folks go around making misrepresentations about the security
of broken versions of it.

> because it would

As well they should, because the current SSLv3 and TLS specs are broken,
in a worse way even than SSLv2.

- Marsh

---

From: Kyle Hamilton <[email-masked]>
Date: Thu, 17 Dec 2009 14:55:22 -0800

I support making the MCSV mandatory in the ClientHello.  The benefit
is obvious: the server *knows*, without a doubt, that the client knows
how to do secure renegotiation, even if the client doesn't send the
extension.  This means that servers can relax their "absolutely no
renegotiation" stance, in regards to that particular client, in the
same way that they could if they received the extension.

As far as I can tell, there is no mechanism (other than extensions)
for the server to signal the client that it knows how to do the secure
renegotiation.  As has been discussed, this would be a static set of 6
bytes appended to the ServerHello.

I rather disagree with making the RI extension anything other than
empty, because each peer *must* (in order to implement it securely)
remember the last hashes for that session and compare them to see if
they match, else the MITM could just add bogus information that isn't
checked and the handshake proceeds anyway -- which violates the
authenticity guarantee.  If we're going to force the implementors to
save the hashes anyway, why should we take the risk of putting them
out on the wire?  (To avoid a "chosen plaintext" attack... against a
key and negotiation that's about to change?)  If the values calculated
don't match up with what's received from the other end, the
ChangeCipherSpec will work but the Finished message won't be able to
be decoded, which will cause the connection to be aborted.

(However, I do recognize that putting the prior hashes into an RI
extension will cause them to be part of the final hash for Finished
anyway, without requiring any changes in how the cryptographic system
is set up.  I'm unhappy with this idea, though, because there are
still MANY extension-agnostic clients and servers out there.  Clients
won't send extensions if they don't have to, and servers won't show
that they know about extensions unless the client shows exactly the
extension they expect.)

If those hashes are saved by each peer (as would be required under
this proposal), then it follows that since they're placed under
separate cover by the Finished message, they're an appropriate input
for the Renegotiation-Finished hash calculation.  Again, there's no
reason to put them on the wire.

What we're looking for isn't really a "session-based" design -- we're
simply looking for a way to authenticate future handshakes as
following naturally from prior handshakes.  The session parameters are
frozen by the time ChangeCipherSpec hits; the Finished message is and
always has been the time to determine whether the peer understands the
cipher spec parameters.

Also, it is illegal for any TLS implementation to negotiate
NULL-NULL-NULL, and it is illegal for any TLS implementation to
transmit application data after the initial handshake has been
initiated and before the Finished messages have been generated by both
sides.

This would suggest that another mitigation for this attack would be to
include a zero-length application-data packet in all renegotiations;
if one side thinks it's an initial negotiation, and it receives an
application data packet under the state that it thinks is
NULL-NULL-NULL, it is required that it close the connection with a
fatal handshake_failure alert.

(The only problem with this potential mitigation is that if the client
is connected to the MITM, and the MITM is connected to the server, the
MITM could simply strip out the zero-length application-data chunk,
since TLS relies on underlying mechanisms to verify that it has a
two-way error-detected/corrected clear channel -- TCP/IP, SPX/IPX, a
clean serial line, or an MNP5 modem.  TLS doesn't try to detect lost
chunks from the server.)

So, in addition to mandating the MCSV, I also support an empty RI
extension as a means of notifying the server that the client knows how
to do it.  For interoperability and ease of implementation, it's an
easy MUST to send both, if the client understands how to send
extensions.  I'm less happy about forcing the client to understand
extensions enough to verify the data being put into the RI extension
on subsequent handshakes, but even in that case the ServerHello
wouldn't have the correct 6 bytes at the end (for the initial
handshake that the client sees) and thus would cause the client to
abort with a handshake_failure.

(Since the cryptographic properties of the protocol aren't being
discussed, it's only a matter of identifying what oversight in the TLS
protocol allowed this attack to work, which is simply that a means was
found to trick both sides of a connection into believing that the
connection was continuous without cryptographic verification.)

At least one good thing that the original protocol designers did was
to ensure that both peers must renegotiate their own cipher parameters
in the event that either side initiates a renegotiation.  Since it's
mandatory that servers include the bytes after the end of the
ClientHello as part of the hash of handshake messages, regardless of
whether it can identify them or not (this was the language previous to
TLS-EXT), the client can send anything it wants.

The server side is a bit more complex: it can't signal anything to the
client unless it uses an extension.  For the client, it's very easy to
compare 6 bytes in memory to verify that the extension exists and is
the proper one.

It's only if the Finished message happens and it doesn't have the
correctly-seeded hash that it's detected as being bogus.

(Notably, the TLS specification requires that after the initial
negotiation, applications need to be able to interleave data into the
connection -- except in the case of ChangeCipherSpec and Finished,
where Finished must always be sent immediately after the
ChangeCipherSpec is sent.  A way to break compatibility with older
clients would be to send a zero-length, HMAC'd application data chunk
between the ChangeCipherSpec and Finished messages, using the cipher
suite that was put into the current connection state by the
ChangeCipherSpec, not count it as a handshake message, and only after
that send the Finished message precisely as it is calculated
elsewhere.  I would prefer that it not be broken, but it could be a
means by which TLS 1.3+ ensures that the handshakes under its own
cover are acceptable.)

Once a handshake determined to be bogus, the spec is clear: abort the
connection with a handshake_failure alert.

I support making what I see is the minimum number of changes in the
specification necessary to ensure security, in such a way as to
minimize the amount of work to implementation developers.  If there is
a way that is simpler, I would like to see it.

(I'm wondering if it's time to start making breaking changes, and call
the result TLS v2.0.)

-Kyle H

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 00:07:58 +0100 (MET)

> > a core element of SSLv3/TLS and is optional-to-implement.

There seems to be an illusion that this secure TLS renegotiation
update can be forced upon vendors or implementors.

No, it can not.

There is an incentive called "competitive advantage", but it does
not apply to commodity items in the consumer market that are 2+ years old.

If you can force anything from those vendors, then it is a switch
to disable old renegotiation, in case that is (unintentially) available.
That's it.

If you really want to do the community a favor, then this update
should be so "small&easy" for those vendors that they can actually
put it into installed base, even when that is 2+ years old.

If the IETF's "solution" is that you can only implement the
whole schmear or nothing, then this is not going to happen to
the installed base -- and it is not the fault of those vendors,
they can point to the IETF, because of a new spec that may cause
their customers interop problems in the future.

Some vendors will appreciate this as a "business opportunity",
but I think this is a big waste of money.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 17 Dec 2009 15:36:23 -0800

Kyle Hamilton wrote:
> .....  If we're going to force the implementors to
> key and negotiation that's about to change?)

I was going to say, "The RI data sent over the wire is protected with
the same security as it was when it was in the Finished messages."

But actually, that's not entirely true; the client's Finished message
gets exposed on the server-to-client link in a renegotiation, where it
was previously hidden (due to different keys used in both directions).

Perhaps RI from server-to-client should just be the server's previous
Finished message, as I believe Bodo suggested weeks ago.

> that they know about extensions unless the client shows exactly the

Simply sending the prior hashes within RI extensions does not offer
any security whatsoever.  Both sides need to verify that what they
receive matches what they remember from the prior handshake.  This is
a known problem; a peer that forgets to check is still completely
vulnerable.

> reason to put them on the wire.

You're right that there is no need to put it on the wire, but then you
need to come up with a way to incorporate the old verify_data into the
renegotiation Finished message calculation.  Martin's draft suggests
one way to do that, though many seem to prefer to wait until the next
version of TLS to define that, since there will be lots of time to
design it properly.

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Fri, 18 Dec 2009 05:25:34 +0000

> clean serial line, or an MNP5 modem.  TLS doesn't try to detect lost

Unfortunately, this problem is a fatal objection to what was otherwise
a very interesting idea:

 - If the extra record is sent before the ChangeCipherSpec of a
   renegotiating handshake, then the attacker can strip it out
   (because it won't be included in the handshake_messages,
   and it doesn't affect the sequence number of messages after the
   ChangeCipherSpec, which resets the sequence number to zero).

 - If the extra record is sent after the ChangeCipherSpec but
   before the Finished message, then (by my reading) the receiving
   peer MUST treat this as a fatal error regardless of whether it
   believed the handshake was initial or renegotiating.