Minutes for TLS at IETF-86
minutes-86-tls-1

TLS WG
Minutes from Paul Hoffman (edited by EKR)

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 requirement from HTTP is that
the protocol
                allows 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 advertisement 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 -- need to pick something
        Counting: 25 ALPN   12 NPN
        Ekr: We still want to work on hiding more
        Sean: That would need to be in a 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
        Certificate Transparency.
                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