Re: [TLS] Informal minutes from Orlando

[Russ Housley <[e-mail]>]

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


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

> 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
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls