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