Subject: [TLS] TLS CBC ciphersuites fix

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 14 Apr 2013 11:29:18 +0200

Hello,
 I don't know if the issues in CBC ciphersuites topic was discussed in
the previous WG meeting (couldn't find the minutes), and I don't know if
there is already a selected solution, but here is a summary of the 3
proposed (in the list) fixes to the CBC issue so far, as well as my
thoughts on each one (note that I co-authored II).

===================
I. http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01
Specifies ciphersuites using CBC to be used with the TLS 1.2
AEAD construction. It utilizes the encrypt-then-MAC construction.

* Pros:
1. Provides ciphersuites that can be used to replace the existing
existing CBC ciphersuites.

* Cons:
1. The new ciphersuites only work in implementations supporting TLS 1.2
2. It adds 5 new ciphersuites using AEAD and various HMAC-SHA variants.
Cannot be used to replace all known CBC ciphersuites.

II. http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00
Modifies all ciphersuites to use a new padding mechanism that does
not have the shortcomings of CBC padding. That is, padded data are
part of the plaintext.

* Pros:
1. Fixes the known issues in all the existing CBC ciphersuites.
2. May be used from SSL 3.0
3. May protect from key-recovery in a weak MAC construction
4. It adds the ability of variable padding to all TLS ciphersuites

* Cons:
1. May not protect from a MAC that has data-dependent timing
2. Modifies all TLS ciphersuites, even those not affected by the attack.

III. http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-01
Negotiates an encrypt-then-MAC mode for all TLS ciphersuites.

* Pros:
1. Fixes the known issues in all the existing CBC ciphersuites.
2. May be used from SSL 3.0 (though the text mentions TLS 1.0 only)
3. May protect from a MAC that has data-dependent timing

* Cons:
1. Modifies all TLS ciphersuites (except the AEAD), even those not
affected by the attack.
2. May not protect from key-recovery in a weak MAC construction
===================

Please feel free to add an pros or cons I missed.

I find solution (I) inadequate to replace the CBC ciphersuites in any
practical scenarios. That is because that solution only works for TLS
1.2 implementations leaving all the older ones vulnerable.

What I like most in solution (II) is the variable padding to any TLS
ciphersuite which can be used as a traffic analysis countermeasure. The
other thing I like is that it fixes the issue at hand by doing minimal
changes by preserving the original construction used in TLS
(MAC-then-encrypt).

Solution (III) what I like most is that it fixes the issue at hand and
potentially any other timing issues that may arise from a MAC that has
data-dependencies. What I don't like is the radical change, i.e., a
switch to another encryption mode which leaves the MAC unencrypted.
Maybe it should be combined with a deprecation of HMAC-MD5, and possibly
a truncation of the MAC to deter key recovery (remember that the TLS
handshake MAC is already truncated to 96-bits exactly for that reason).

Any other thoughts on those issues? Is the WG actually adopting a fix to
that issue, or should implementors work it out outside the WG?

regards,
Nikos

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 14 Apr 2013 08:24:27 -0700

On Apr 14, 2013, at 2:29 AM, Nikos Mavrogiannopoulos <[email-masked]> wrote:

> the previous WG meeting (couldn't find the minutes)

I volunteered to take minutes at the meeting, and sent them to the chairs immediately after. They did not post them, so they are not part of the official IETF proceedings. Below is what I sent them.

--Paul Hoffman

TLS WG
Minutes from Paul Hoffman
Stuff from slides is not reproduced here; see https://datatracker.ietf.org/meeting/86/materials.html#tls

draft-ietf-tls-cached-info, Hannes Tschofenig
	One open issue
	Instead of sending the fingerprint, server just sends empty Certificate payload
	More elegant from an implementation standpoint
	Adam Langley: Do we hash them all, always?
		Doesn't want to paint ourselves in the corner
		Not optimizing how much you would send.
		Ekr: Server hello lists all of what will be omitted
		Joe: Could add types for omitting intermediate certificates only
	Next version will be out next week

Next prototocol negotiation
	HTTPbis WG wants this so that someone can tell which version of HTTP is being used
	draft-friedl-tls-applayerprotoneg, Andrei Popov
		Hiding things from snooping should be generic for all data
	draft-agl-tls-nextprotoneg, Adam Langley
		NPN is used for negotiating SPDY today
		IANA will certainly change extension number that was picked
		(Looking at previous slides' chart): Client sends its message "here"
		Wish to avoid sending anything in the cleartext
		Does not receive the same guarantees that TLS provides
			Uncomfortable grey area between "confidentail" and "secure"
		ALPN reflects everything else we do in the normal TLS handshake
			But that makes it less robust
		If the TLS WG goes with this, NPN will be dropped
		Also wanting put other stuff in the protected-but-not-secure road
		Burning a round trip in renegotiation is not viable
		Martin Stiemerling: Why would someone blocking not base on the server's list?
			Adam: server doesn't have to actually list anything
				Client can pick whatever it wants, even what isn't 
		Ekr, wearing chair hat: The specification must allow negotiation
		Yoav Nir: We like creating frameworks for solving problems
			Why should we have any negotiation of HTTP
		Mark Nottingham: The request from HTTPbis WG was to have this be open-ended
		Roberto Peon: Negotiation is needed during protocol development
	Ekr: The negotiation needs to advertise and the other side can select
		Adam: Had a different design
		Adam: Want a common advertisment so that middleboxes cannot use the advertisement to block
	Mark: The list doesn't need to be complete
	Hannes: Privacy concerns drive the protocol design
		Adam: not really a privacy concern because the the security is complete; think robustness instead
	Gabriel Montenegro: Twitter today doesn't negotiate: it goes straight to SPDY
		Doesn't like the encryption without the final handshake
		Adam: Because False Start is being used, you have nearly the same security guarantees
	Martin: The problem is that we have different servers wanting to different things
		Advertisements help us to determine that
		Mark: What is the contentious point?
	Ekr: We have two designs with very different properties
		NPN violates the TLS state machine
		Wants to have significant parts of the handshake covered
			Maybe we can do this today
	Cullen Jennings: Concerned how many firewalls block what they do not understands
		Thus would rather expose instead of hide
		Not a real privacy loss
	Andrei: Slippery slope of partial protection from passive attack
		False start is predicated on a strong cipher, so not really comparable
		You don't want to restrict the ciphers;
		Adam: wants to restrict it to strong ciphers to make people upgrade
	Ted Hardie: in Tor bridge ALPN lets you do an early stop, in NPN it terminates later
		Adam: Was just using Tor as an example
		Ekr: For Tor, now it is just a cross-protocol attack
	Joe Salowey: Concerned about the middle-ground
		Wants to protect the handshake in a more robust way
	Brian Dickson: What is the list of protocols?
		Adam: ASCII strings
		Brian: client may be shoehorning itself
		Adam: We don't care for SPDY, but that doesn't help my case
	Mark: Doesn't want this to drag out
		HTTP1 and 2 are semantically equivalent
		Tokens have roughly the semantics of a TCP port
		For Tor, it could be hidden much lower in HTTP
		Personal bias was towards NPN, but is now neutral
		Maybe wants the server to choose
	Dan Harkins: Doesn't like either because it's not the job of TLS
	Ekr: Server picks is the way things are done in TLS
	Martin: How do the guarantees on NPN affect MITM attacks?
		Adam: Good/bad thing about NPN is that works with proxies
			We are already sending data with False Start so it is not different
		Ekr: The client must verify the server certificate before emitting the NPN client message
			This moves the host name check up
	Roberto Peon: Data from doing different protocols over 80: bad; other port, almost as bad; 443: no problem at all
		If we make it easy for people to see it, we'll have to design this again later, doesn't want to that
		Ekr: Doesn't agree that hiding the selected protocol is better
			Intermediary will break client hello based on TLS 1.1
	Andrei: Devising a protection scheme for one piece of data is not good; be more systematic
		Will lead to double encryption
		Adam: Agrees, and thus put it in Encrypted Extension block 
		Andrei: Maybe use Marsh Ray's proposal
	Cullen: APLN will get through firewalls better
	Straw poll:  ALPN hummed slightly louder
	Russ Housley: Donkey between hay
	Counting: 25 ALPN   12 NPN
	Ekr: We still want to work on hiding more
	Sean: that will be TLS 1.3

TLS authorization using DTCP certificate
	draft-dthakore-tls-authz, D. Thakore
	Additional authentication type that is mostly for audio-visual content
	Update to IPR will have licensing terms
	Chairs will figure out why it has not been published
	Adam: RFC 5878 has a lot of problems that prevented it working for CT
		Errata have been submitted
	Currently individual submission, will figure out with Sean
	Will have a later glance in the WG

TLS over LLCP
	draft-urien-tls-llcp, Pascal Urien
	All about NFC (near field communication)
	Wants to put TLS between SNEP and LLCP
	There is an implementation available
	Wants advice from WG on how to make profile
	Ekr: break this into two drafts: LLCP and TLS issues
	Hannes: LWIG has implementation guidance
		Lots of other LWIG drafts and COAP drafts deal with this

---

From: Russ Housley <[email-masked]>
Date: Sun, 14 Apr 2013 11:44:03 -0400

http://www.ietf.org/proceedings/86/minutes/minutes-86-tls

On Apr 14, 2013, at 11:24 AM, Paul Hoffman wrote:

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

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 14 Apr 2013 08:54:19 -0700

> http://www.ietf.org/proceedings/86/minutes/minutes-86-tls

Ah, excellent. I assumed they hadn't because they hadn't had the WG review them first.

Fortunately, we have time to fix the line-wrapping problem before the final proceedings. :-)

--Paul Hoffman