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

IETF 96 Transport Layer Security (TLS) Minutes
Date: Tuesday Morning Session, July, 19, 2016
Location: Berlin, Germany
Chair: Joe Salowey, Sean Turner in absentia.
Minutes: Jim Schaad
==============================================

Administrative Trivia:
    Done with success.

Document Status:
    DKG (Daniel Kahn Gillmor): Should get Auth48 done soon
    YN (Yoav): 4492-bis - new version recently.  Maybe ready for last call. 
    May need to wait on CFRG KP (Kenny Patterson): Getting close to EdDSA being
    done.  Some implementation details need to be ironed out.

TLS 1.3 Document update - EKR (Eric Rescorla)
        Called out change in warning level alerts where I am not closing the
        session. Call out a note where server cannot wait for the
        end_of_early_data message because of potential dead lock.  Want to
        allow client to continue sending data until it gets the server hello.
        MT (Martin Thompson): Post-Handshake Key Separation - What is here is
        great. No additional discussion on this issue.

        Cipher Suite Negotiation: (Break Up Monolithinc cipher code points)1
                MT: Allows for post-quantum by just defining a new named group.
                EKR: Lose the ability to express some combinations where
                specific things MUST be linked - example of Fortezza given. MT:
                Can still make some decisions in the server to remove options
                based on other selections.  I.e. P-521 might eliminate 128-bit
                AES.

                DKG: Offering static DH and no signature. - call that static DH
                signature?
                        Becomes less orthognal of mix with signature algorithms
                ??:
                EKR: May not be supporting some of the JPAKE type algorithms in
                the future STP: Are we still supporting the not recommended
                column in the registry? MT: In terms of PAKES - separate
                exercise for supporters. David Benjamen(DB): Can still use
                extensions to do strange things to support. Russ Housley (RH):
                hash in signature and hash in PRF are distinct in the choices. 
                Can result in mismatches of the hashes EKR: That this a feature
                or flaw depending on how you look at it. EKR: Client must offer
                a consistent profile if needed. ??: Why negotiate the PRF here.
                 Make it separate EKR: Does not seem to add a lot of value. 
                But yes could do it. Yaron Sheffer (YS): If forcing to send
                multiple proposals - might be good to say that this is a
                proposal but other proposals exist. EKR: All ready can say
                incoherent things today. DKG: want to think about version - do
                they mean things between 1.3 and 1.2 EKR: No these are empty
                intersection groups. MT: Have that problem already today with
                existing suites.  Some today are already version restricted.
                        Commit to version and then go from there

          JS (Joe Salowey): Sense of the room is this is a good change
        PSK Suite Negotiation
                MT: Gives a chance for implementations to add some checks on
                where and if entropy is being added to the system. EKR: This is
                another orthogonal (more or less) piece the the rest of the
                Chinese menu on the previous slide. EKR: Allows for PSK for
                client auth w/ server signature for it's proof of id. EKR:
                Treats PSK as special case of resumption. RS (Rich Salz): How
                is this being configured? MT: Have stuff in NSS that allows for
                this to deal with ordering and turning on and of each of the
                items individually. DB: Probably want to do some type of post
                process extract for dealing with backwards considerations on
                ordering. DKG: Wondering if implementers could look at and
                present a string version of how these should be represented for
                both client and server.  Lead to consistent representation.
                Dev: How are the security considerations for this is going to
                be done?  Making things same-ish DB: Don't need a language
                unless you want to do some matchy-matchy things of grouping.
                DKG: Standard string format makes cross implementations easier
                to deal with. SF (Stephen Farrell): Might want some type of
                "enough" or turn off capability to deal with algorithms going
                bad.

        HUM:
                Do you support this change? Substantial
                Oppose: None

        Version Negotiation
                DB: Want to do this for a large number of the lists.  Burn some
                section and check for errors by sending some strange things on
                a regular basis. MT: Want to stop after the first bullet point.
                 Version upgrade based on some extension being present and make
                sure that all new versions of tls have a required new extension
                defined. DB: I can be happy with either method. EKR: New
                extension would not allow for preference order. ??: Would allow
                for an indication of that middle versions are not supported. 
                I.e. 1.0 and 1.3 only. EKR: Allows for unofficial forks by
                using unregistered values. EKR: The old max/min pair never
                worked. Erik Nigen(EN): How much of the negotiation is sever vs
                middle boxes.  This is going to be worse for that for now. DB:
                Intolerant middle boxes seem to be all gone and hopefully will
                stay that way. DB: May still be problems on version number
                checking. ??: Extension marking will not work if only want to
                do 1.3 MT: Will not have anything in common with the server and
                fail.
                        For current time can disjoint cipher suites
                Andrey Popov: This can be a UI problem as the missing in the
                middle items might be a need to show it in the UI.

                HUM:
                        Do you favor changing the current negotiation
                        mechanism? low hum Oppose: Relatively large hum

        PSK and Client Auth
                Hannes (HT): Confusing because two types of client auth.  PSK
                w/ session resumption client auth makes more sense to re-prove.
                ??: Makes implementation harder -need to remember previous
                state harder.  Do you need to get a cert after end of client
                data.  Rather than be in a state of expect client finish or
                client cert vs only expect client finish. EKR: Agree - had the
                same issue as well. EKR: Server can prove it still holds key
                via signature but not for client until post finish. EN: Makes
                it harder to deal with the case where a holder of the session
                ticket key can do faking of any client.  Sad that one of the
                mitigaters is going away. DKG: That is a very bad situation
                anyway.  Not a great deal of sympathy.

                Chair: No objections to doing the ban step going forward.

        Resumption Contexts and 0-RTT Finished.
                A (Antone Delignat Lavaud): Currently an attack in the current
                draft about this.
                        This is only for external application PSK.
                EKR: Does the attack require sharing keys?
                A: Yes
                MT: How do you decide on the PRF hash in this context?
                MT: Need a finish for all of the PRF hash and PSK key pair in
                order to do the FINISH at the end of the extensions. EKR: This
                is a problem for the non-zero RTT Mode A: There exists a method
                to generate a resumption context which matches the resumption
                case for the PSK case. Chair: Need to have a discussion on the
                list for this issue.

        Multiple Concurrent Tickets
                MT: Not sure what properties we are looking to get out of this.
                EKR: Looking for the set of tickets which are currently valid 
                Could just set a list of tickets still valid MT: Flag which
                says all previous tickets are dead.
                        Prefer just dump a lot of tickets and suggest use the
                        last one.
                DKG: Multiple tickets are needed to prevent linking.
                        Need to send note when server state has changed so
                        state associated with a ticket is running. Example is
                        mid-stream client auth added to the ticket state.
                MT: No value of doing cross session invalidation of tickets.
                EKR: Could use a ticket extension later if needed.
                AP: Batch replacement of multiple tickets would be a workable
                solution EKR: Can live with this, for this connection. MT: EKR
                is talking about how we do this today on browsers.  Blow away
                all old tickets from the same origin when new tickets come in. 
                Could change this in the future, but why bother? EN: Another
                use case is better key rotation practices.
                        Would allow for different keys per cluster.
                        Keeping the semantic of multiple alive helps here even
                        if it might hurt privacy semantics
                MT: We have now identified the bike shed and we should let a
                small group start painting it.

        Last-minute thought: EE in Second Flight
                MT: No this should be done with new handshake messages and
                since we don't have use for it now. EKR: Neither do I.

                Chair: will need list discussion

receive_generation field in KeyUpdate - Keith
        Chair: are there objections to this approach?
        DKG: Seems to collapse two semantics of - I am using new key and I have
        delete old key. KW: On receipt it is required to ratchet keys forward.
                No reason to keep old key.
        KW: Key is no longer usable for trusting incoming traffic - do not use
        not it is delete. EKG: The key could be leaked to a third party and
        they can learn history, but cannot produce new traffic. SF: Not sure
        that it has been properly discussed on the list. YN: it is a TCP stream
        - why is the number needed? MT: Saying things about the opposite flow
        of data - what the other side is doing/has done.