[TLS] Informal minutes from Orlando

[Paul Hoffman <[e-mail]>]

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

> I don't know if the issues in CBC ciphersuites topic was discussed in
> 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