Subject: 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: Paul Hoffman <[email-masked]>
Date: Wed, 16 Dec 2009 08:22:35 -0800

At 4:05 PM +0100 12/16/09, Martin Rex wrote:
>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: 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.

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: 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: 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: 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