Minutes for TLS at interim-2014-tls-4
minutes-interim-2014-tls-4-1

TLS WG Interim
Honolulu, HI
Sunday, Nov 9 - 2014
0930 - 1530
Chairs: Sean Turner, Joe Salowey
Notes: Paul Hoffman
----------------------------------------------

General agenda:
        Session resumption
        Key refresh / client autho
        0-RTT
        OPTLS signature-less stuff from Hugo

Blue sheet equivalent was passed around

Resumption
------------------
        Two kinds of resumption:
                Classic: session IDs, same in 1.3 as in 1.2
                Tickets: RFC 5077 style
        In Paris, suggestion was session IDs, cookies, and PSK can be combined
                Can be arbitrarily large
                Treat session resumption as PSK, or treat PSK as session
                resumption?
        Some PSK modes offer PFS, but some do not
        PSK modes are currently broken in TLS 1.3
        Questions about modes that use PSK for authentication and also to mix
        into the keying material Maybe we can throw away the public key PSK
        modes PSK mode would be a separate ciphersuite(s) For now, only repair
        the non-public-key PSK ciphersuite Questions:
                What's the format of the ticket?
                Which PSK modes do we want to get back?
                Is it OK for us to have a master secret used on different
                ciphersuites? Do we need to know ahead of time if we are doing
                a resumption or a new PSK session?
        Conclusions:
*                 We probably want to retain the DHE modes
*                 Want tickets to work
*                 Want tickets and session IDs to be the same
*                 People want to see a design of the unification
*                 Want session resumption is essentially a PSK ciphersuite

OPTLS discussion
--------------------------
        performance win with long-term RSA certs
                Use cert to sign ECDH ephemeral key
                Slightly more effort for the client
        0RTT requires a semi-static key anyway, so this seems similar
        Need to have a signed parameter for every set of parameters I'm willing
        to use Offline signing has some benefits Can be used for delegation
                But we could just design delegation separately anyway
                We need to be upfront about the problems with delegation
        Probably no HSM today will support this
        You can use your current RSA certificate without signing to gain
        performance increase Question: if an attacker can replicate the
        client's PNRG state, can they now impersonate? If you're doing this on
        the client side, things are marginally worse
                Let's decide first if we're doing it on the server
        This is to replace all the signature modes, not adding new ones
        The format of blob will be hard
                Might include the server identifier
        Could all be fixed with just getting ECDH or ECDSA certs

Lunch was had

* Performance benefit only helps with RSA signing, if you use ECDH or ECDSA
certs then it is less improvement * Delegation needs to be designed for *
Complication to the key schedule also causes some worry *  Almost no support in
the room for OPTLS today; consensus of room against

Back to session hash
----------------------------
        How to decide when to compute the server finished
        Would be nice for the server know if there will be client
        authentication early on Question of whether CertificateVerify appears
        in the master key Because you want the client certs hashed in for
        resumption, you have to synthesize another last key Update updates the
        binding identity/ticket to the session The server being able to send a
        first message in HTTP/2 before it gets a client cert is useful Perhaps
        no need to provision tickets during handshake Possibly resurrect Ekr's
        earlier proposal for Update
                http://www.ietf.org/mail-archive/web/tls/current/msg13966.html
                Add a restriction that the client can do so only once
        Removed the gratuitous ChangeCipherSpec

Client auth
----------------
        Server has to be able to say which signatures it can verify
        Certificate Request is both badly messed up and also useful for client
        UI
                Difficulty of "an issuer" vs. "the issuer"
                Do we want some additional OID matching?
                Useful for servers to be able to control the client experience
                This is really for HTTP because other TLS users don't have as
                much UI issues Client cert caches exist
        We can't nuke certs, but maybe leave this alone so that it goes into
        HTTP/2
                EAP-TLS uses some of this filtering
        Microsoft folks will look into what kind of things they want in future
        for client filtering

Single point format
--------------------------
        Proposal: every new curve comes with a format
                All current would use uncompressed points
                No more point negotiation
        Proposal:
                - Each curve code point has one representation
                - The existing NIST curves will have an uncompressed
                representation - We will remove point representation
                negotiation - If we want to add a compressed format for the
                existing curves we will define a new code point
        Feeling of the room was to support this
        Maybe remove some of the weak and the less-used curves
        Set the minimum strength to 128 bits

-------------------------
OK to remove Tim’s name from the author list and add to contributor section?

No objection in the room