Subject: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

From: Eric Rescorla <[email-masked]>
Date: Mon, 07 Dec 2009 14:02:44 -0800

Hi folks,

I've been going through the list discussion on
draft-ietf-tls-renegotiation and wanted to try to close on some of the
edits people have proposed.

1. Replace "cipher suite" with magic cipher suite value (MCSV) 
   throughout.

2. Add "Updates: RFC 5246, 4366, 4347". Pasi, should we be explicitly stating
   4346 and 2246? ISTM we already transitively update them, but I don't
   care either way.

3. Rewrite the introduction along the lines suggested by Marsh Ray, 
   Nicolas Williams, David-Sarah Hopwood, and others to more accurately
   capture the entities which are being spliced here. I will propose
   new text on the list.

4. Channel bindings: replace the end of S 1. with:

   "The data used in the extension is similar to, but not the same as, the
   channel binding data used in [I-D.altman-tls-channel-bindings], however
   this extension is not a generic-purpose RFC 5056 channel binding
   facility."

   Nico, did you have other text you wanted?

5. Explicitly state that this extension also applies to DTLS and
   that the same normativity levels apply.

6. Explicitly state that this extension may also be used with
   SSLv3 (we don't have any authority to update SSLv3 in any
   way but we can certainly say that there is no technical
   obstacle.)

7. Clarify that RI MUST be generated in all rehandshakes, per the
   issue Martin raised earlier and proposed resolution by Marsh
   and Nelson.

8. Rewrite the introduction to more clearly elucidate 
   the impact on app-level protocols. As Chris Newman has pointed
   out it currently apples primarily to HTTPS, but we should have
   some non-HTTPS text. I will propose new text on the list.

9. Rewrite the section about identity changes in Security Considerations.
   I'll propose new text on the list.

I'll also make whatever small editorial changes I see. 
If I've missed something important that people think there is
consensus on, please let me know. There are a lot of messages, 
so I may well have.

Best,
-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Dec 2009 16:37:14 -0600

>    Nico, did you have other text you wanted?

RFC5056 needs to be an actual, informative reference.  Also, since we
use both Finished messages this resembles the tls-unique-for-telnet CB
most:

   The data used in the extension is similar to, but not the same as,
   the tls-unique and/or tls-unique-for-telnet channel bindings
   described in [I-D.altman-tls-channel-bindings], however this
   extension is not a generic-purpose RFC 5056 [RFC5056] channel binding
   facility."

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 07 Dec 2009 15:00:59 -0800

At Mon, 7 Dec 2009 16:37:14 -0600,
>    extension is not a generic-purpose RFC 5056 [RFC5056] channel binding
 
Sold.

-Ekr

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 08 Dec 2009 00:09:12 +0000

>>    the tls-unique and/or tls-unique-for-telnet channel bindings

the data used in the tls-unique and/or tls-unique-for-telnet channel binding
types

>>    extension is not a generic-purpose RFC 5056 [RFC5056] channel binding

generic-purpose -> general-purpose

> Sold.

+1.

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

---

From: <[email-masked]>
Date: Tue, 8 Dec 2009 10:04:27 +0100

Eric Rescorla wrote:

> 2. Add "Updates: RFC 5246, 4366, 4347". Pasi, should we be explicitly
> stating 4346 and 2246? ISTM we already transitively update them, but 
> I don't care either way.

Yes, we should -- since this document is fixing an important bug 
in 2246/4346, we want "Updated by RFCNNNN" to appear in the RFC 
index for 2246/4346, too.

Best regards,
Pasi

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 08 Dec 2009 12:47:54 +0000

> consensus on, please let me know. There are a lot of messages, 

In 6.1:

   If clients wish to ensure that such attacks are impossible, they MUST
   terminate the connection immediately upon failure to receive the
   extension without completing the handshake.

Should we be more specific about what "terminate the connection" means? Does
that mean drop the connection immediately without sending anything else or by
sending a fatal alert? If a fatal alert which one? Presumably handshake_failure?

I'm thinking here in terms of sending something useful which would most likely
appear in server logs to help diagnose the cause: i.e. unpatched server which
strict clients refuse to connect to.

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: Marsh Ray <[email-masked]>
Date: Tue, 08 Dec 2009 09:38:36 -0600

Dr Stephen Henson wrote:
> Eric Rescorla wrote:
>> I'll also make whatever small editorial changes I see. If I've
>> missed something important that people think there is consensus on,
>> please let me know. There are a lot of messages, so I may well
>> have.
>> 
> 
> In 6.1:
> 
> Should we be more specific about what "terminate the connection"
> means? Does that mean drop the connection immediately without sending
> anything else or by sending a fatal alert?

The spec says "Upon transmission or receipt of a fatal alert message,
both parties immediately close the connection."

> If a fatal alert which one? Presumably handshake_failure?

How about 'unexpected_message'? That's what I see when mixing
application data into a renegotiation handshake that wasn't expecting it.

RFC 4346 defines it as:
> unexpected_message An inappropriate message was received.  This alert
> is always fatal and should never be observed in communication between
> proper implementations.

> I'm thinking here in terms of sending something useful which would
> most likely appear in server logs to help diagnose the cause: i.e.
> unpatched server which strict clients refuse to connect to.

That would seem to set off the appropriate alarm bells.

- Marsh

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 08 Dec 2009 17:01:45 +0000

> application data into a renegotiation handshake that wasn't expecting it.

Just to be clear here: I'm not referring to an attack but where we have a strict
patched client that refuses to connect to an unpatched server. That is client
makes initial handshake using RI+MCSV, doesn't get RI back and decides this is
not acceptable.

This is a scenario which is quite likely to happen at some point. Well it
happens already in my test environment ;-)

I'm asking whether a client should send a fatal alert here so a server admin can
get some hint of the cause or if it should just silently drop the connection.

Steve.

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Dec 2009 18:24:09 +0100 (MET)

Dr Stephen Henson wrote:
> 
> Just to be clear here: I'm not referring to an attack but where we have
> a strict patched client that refuses to connect to an unpatched server.
> That is client makes initial handshake using RI+MCSV, doesn't get RI
> back and decides this is not acceptable.
> 
> I'm asking whether a client should send a fatal alert here so a server
> admin can get some hint of the cause or if it should just silently
> drop the connection.

If this were a _new_ spec, then I would suggest a SHOULD.

But since we're going back in time, and there seem to be a number
of implementations that are notoriously bad and sending and
receiving SSL alerts, I definitely would not want to create
any false hopes.

In the situation that you're describing, it is the updated client
that determines that it doesn't want continue talking to the old server,
and so the set of available Alerts that could make any sense
to an old server is those known to SSLv3,  IMHO.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 08 Dec 2009 11:25:18 -0600

> get some hint of the cause or if it should just silently drop the connection.

I can't find anywhere in the current RFCs that advocate silently
dropping the connection. In fact it defines it in the opposite direction:

> Error handling in the TLS Handshake protocol is very simple.  When an
>    error is detected, the detecting party sends a message to the other
>    party.  Upon transmission or receipt of a fatal alert message, both
>    parties immediately close the connection.  Servers and clients MUST
>    forget any session-identifiers, keys, and secrets associated with a
>    failed connection.  Thus, any connection terminated with a fatal
>    alert MUST NOT be resumed.

As a TLS library, you might not always have an actual socket handle. It
may be require rarely-used code in the application to actually "close
the connection". Application code may not always tell you when a socket
has been closed, so you may not have the opportunity to clean up and/or
log messages about the event.

I think using the currently defined fatal alert protocol is appropriate
here.

- Marsh

---

From: Michael Gray <[email-masked]>
Date: Wed, 9 Dec 2009 06:40:48 +1000

> 2. Add "Updates: RFC 5246, 4366, 4347". Pasi, should we be explicitly
stating
>    way but we can certainly say that there is no technical

I would request that this needs to include sufficient technical details
e.g. the size of the verify_data values etc.

>    I'll propose new text on the list.

I additionally request guidance be included in Section 5 on safe probing of
Servers during initial connection to prevent outages in environments that
may include extension intolerant servers as per:

Note :  In cases where a ClientHello protocol behavior change from not
sending extensions to sending extensions is a risk where legacy Servers may
exist that are extension intolerant then the Client MAY mitigate this risk
on initial connection by sending the TLS cipher suite
"TLS_RENEGO_PROTECTION_REQUEST" and SHOULD NOT send the
"renegotiation_info" extension unless the Client is sending other
extensions.

SA http://www.imc.org/ietf-tls/mail-archive/msg11082.html

- Thanks
- Mick Gray
- IBM

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

---

From: Martin Rex <[email-masked]>
Date: Wed, 9 Dec 2009 00:36:55 +0100 (MET)

>    way but we can certainly say that there is no technical

What we're doing is giving recommendations to implementors what
to do in their implementations when protocol version { 0x03, 0x00 }
is negotiated.  We do not need any formal authority to do so.

I would suggest to mention the sizes of the SSLv3 finished
messages (36 octets), since these are considerably larger than
in TLS (12 octets).

>    issue Martin raised earlier and proposed resolution by Marsh

Please add that this applies to _all_ handshakes, including
TLS session resumes, i.e. the Server must return the
TLS extension RI in the ServerHello of a TLS session resume as well!

I feel a little uneasy with the term "rehandhshake". 
I assume you refer to "renegotiation", i.e. a handshake that
is performed when the "current connection state" differs
from "no encrytion, no compression, no MAC".

I realize that the word "rehandshake" was added in one place to
rfc5246 -- but I still would prefer a single term only.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 08 Dec 2009 18:16:48 -0600

> rfc5246 -- but I still would prefer a single term only.

+1, it sounds like slightly loose terminology. Someone could easily
think it referred to session resumption.

There's also another section of proposed text where it emphasizes that
every handshake must be considered independently of all others
(signaling RI I think it was). The term "rehandshake" could be taken to
imply that the same handshake is to be done again (whatever that would
mean).

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 08 Dec 2009 16:28:26 -0800

At Wed, 9 Dec 2009 00:36:55 +0100 (MET),
> messages (36 octets), since these are considerably larger than

I have no problem with any of this. I was just saying that this
seems to be different from the situation with TLS where we 
can say you MUST do X, Y, and Z, and one could say that
implementations were nonconformant if they did not.

> TLS extension RI in the ServerHello of a TLS session resume as well!

Some text to this effect appears earlier, but I'm happy to
add it here as well.

> rfc5246 -- but I still would prefer a single term only.

Good point. I'm fine with using renegotiation throughout.

-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 11 Dec 2009 11:36:49 -0800

> 1. Replace "cipher suite" with magic cipher suite value (MCSV) 

I'm not sure we want to call it "magic" in the RFC (even though I
am probably guilty of calling it that in previous messages).
Perhaps "special" would be a better adjective?

Mike

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 11 Dec 2009 12:38:29 -0700

> Perhaps "special" would be a better adjective?

I think we'd rather be magic than "special" ;-)

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 11 Dec 2009 12:03:01 -0800

> I think we'd rather be magic than "special" ;-)

Well, since the MCSV is an extension, but not a true extension, it
is "special" even in the sense you suggest!  ;-)

Mike

---

From: Bill Frantz <[email-masked]>
Date: Fri, 11 Dec 2009 13:15:35 -0800

>Perhaps "special" would be a better adjective?

Or perhaps, in a moment of candor, kludge cipher suite value (KCSV).

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)356-8506      | around us, is there any choice | 16345 Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032

---

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 11 Dec 2009 21:21:39 +0000

> Or perhaps, in a moment of candor, kludge cipher suite value (KCSV).

The test version of OpenSSL has it set to 0FEC which was roughly speaking my
reaction when I heard of the vulnerability in the first place.

Steve.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 12 Dec 2009 00:22:19 +0000

> Perhaps "special" would be a better adjective?

Signalling cipher suite value?

---

From: Michael Gray <[email-masked]>
Date: Mon, 14 Dec 2009 08:19:38 +1000

> Signalling cipher suite value?

+1

or Probing CSV
or Renegotiation CSV

I also think "magic" should be avoided.

> _______________________________________________
> TLS mailing list
> [email-masked]