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

IETF 91 TLS WG
Thurs Nov 13
0900 - 1130
Chairs: Joe Salowey and Sean Turner
Notes:  taken by Paul Hoffman, didn't copy text from the slides

------------------------------------------------------------------------------------

Three documents might be adopted in the coming months

Current docs
        RC4 deprecation
                General agreement that it needs to happen, disagreement on when
        Session hash
                WG LC is soon
        Downgrading SCSV
                Very close to finished with WG LC
                Martin Thompson: still questions of how the step-by-step is done
                        Maybe specify what version you tried and failed
                Andrei Popov: Would like this to be an extension
                Ekr (Eric Rescorla): There are only a few things, so we can
                just make a few SCSV Martin: Already shipped, and is willing to
                live with the current limitations Ekr: Are we going to break IE
                if we support this? That would suck Andrei: Can live with the
                current draft Martin: Their numbers show the step-by-step is
                stupid Joe Salowey: Will be another WG LC on this More people
                mentioned other weird cases
        Cached Info
                Hannes Tschofenig made some real changes in the last round
                        Wants to be sure that AGL and Ekr are happy with the
                        changes

Finite Field DHE negotiation -- Daniel Kahn Gillmore (DKG)
        draft-ietf-tls-negotiated-ff-dhe
        Most people on the list wanted a baseline of 2048 bits
                Different use cases for what needs to be protected
                Dropped 6144 to reduce fingerprinting
        Tero Kivinen asked about security proofs
                DKG has them
                Question is where to publish them
                        Sean suggested IANA, but maybe somewhere else
        Stephen Farrell asked about reusing IKE groups
                Daniel (DKG): some people wanted each
                Sean: this will come out in WG LC
        Indication of client support
                If the client indicates what it does know, but none that the
                server knows, it doesn't know how to proceed Martin: have you
                considered having a signal to which it knows? DKG: that can
                lead to silly states or confusion Martin: the server must not
                negotiate FFDH without one of the groups that the client said
                Rationale is in the draft
        Server selection indicator
                Number of bytes isn't all that significant
        Alerts
                Questions about what they should say
        Sean Turner: WG LC will ask again if people want IPsec numbers or new
        ones

OPTLS Recap -- Ekr
        Nico Williams: If most TLS 1.3 connections are resumptions, is really
        useful? Dan Harkins: Does the need for generation go away if you have
        an DH cert?
                Ekr: Yes
        ?: Delegation means more than just handing off a key
        Chris Newman: This would be very useful for secondary MX hosts in SMTP
        relay Mike St. Johns: Is the main impetus for this lack of support for
        ECDSA?
                Ekr: Can't speak for others, but this isn't needed if there is
                a lot of ECDSA around
        Phill Hallam-Baker: Wants to be sure that doing the ephemeral doesn't
        weaken the the rest of the strengths

        Impact on server compromise depends on whether you are using HSM
                Some scenarios can turn into a long-term compromise
        Hugo proposed two different types of keys this morning

        DKG: Would we need to define a new PKIX EKU and get them deployed?
        DKG: It is hard for us to discuss this if we don't have a specific use
        case with assumptions Yoav Nir: Could create a new certificate extension
                Ekr: You also need to convince CAs to issue those
        Erik Nygren: Can this be done as a new ciphersuite?
                Ekr: That would be easier with the second flow presented

        Structure of data could be complicated
                People thought a lot more scoping

        Dan Harkins: Doesn't this mean that the client needs to predict the
        group?
                Ekr: this requires the server to generate subcerts for every
                group it uses
        Paul Hoffman: Mostly concerned about the unclarity of what is needed in
        the data structure Joe: If we are going to design a delegation
        mechanism, we should do that very consciously DKG: TRANS WG wants
        auditing for anyone who can act like a CA, and this looks somewhat like
        a CA
                Sean: These certs might be self-issued
        Andrei: Management of the pseudo-cert is lots of extra complexity that
        can lead to error Martin: Very very hard to get this right
                Not enthusiastic to do that much work
                Potentially worth doing later as a new ciphersuite but we
                should continue on our current 1.3 work
        Nico: RFC 3820, proxy certs, are sub-certs
        Dan H: This has a lot of cool properties, supports it
                Likes the idea that one exchange can be used in a multitude of
                environments Martin: We already have one way for those
        Sean: Rough consensus to not do this now

Compressed point format
        Proposal: every new curve comes with a format
                All current would use uncompressed points
                No more point negotiation
        Will merge this pull request

Removing renegotiation
        Will merge this pull request

Session hash, issue 63
        (Mostly the same discussion as on Sunday, see earlier minutes)
        We need two key generation phases, the question is how much of the
        transcript exists Jim Schaad: Is this before or after the certificate
        verify?
                Ekr: We are being more aggressive, not less
        All the handshake stuff is based around the master secret
        Martin: The client now controls the use of resumption
                Ekr: 1.2 and earlier the server always generated a key, and
                someone could use this if they broke the session hash DKG:
                Client can also control the number of times it is reused
        Very few people have read the pull request
        Mike St. Johns: Still worries about key reuse, keys should be single-use
                Ekr: Can do this
        Martin: Handshake traffic keys are bi-directional
                Ekr: Let's talk about this later
        Russ Housley: Likes the hierarchy that is coming up, needs to think more
        Mike St. Johns: Using PRF in too many ways
                Ekr: Needs to rationalize the uses in the text
        Sean: Ask for WG response in the next week

Issue 91: Renegotiation for key refresh
        "Update" exchange
        Responder must ack, even if they don't understand it
        This is used to get new traffic keys
        Can be used to crank the PRF
        But there could be race conditions
                Two different key ladders, one for what you send, one for what
                you receive
        Paul: More complicated than it needs to be. Only one side should be
        able do it.
                Martin: Disagrees that Paul's idea is simpler. Either side
                might feel uncomfortable.
        Erik: Other side could say "please crank now"
        Yoav: Are we worried about the nonce space depleted?
                Ekr: It's 64 bits, so if you use randomly-generated ones, it's
                smaller
        Hannes: This happens rarely

Issue 93: WIP Session Resumption
        For tickets, server doesn't need to hold state
        Session IDs can be issued earlier in the handshake
        Proposal: unify them
        Sam Hartman: TEAP assumed that tickets would never change
                May need an update for 1.3
        Jim: The master secret needs to know about both hashes

Some of these things inter-relate and so please look at the PRs at the same
time.