IETF 93 - TLS working Gorup Minutes Dates - Tuesday, July 21, 2015 and Wednesday, July 22, 2015 Place - Prague, Czech Republic Chairs - Joe Salowey, Sean Turner Minutes - Jim Schaad Revision - 0.1 ============================================================= TLS Meeting Session #1 Chairs: SPT & Joe Salowey ** Agenda Bashing ** WG Status ** TLS 1.3 Status - EKR (Eric Rescorla) PRESENTATION Question on why Finished Secret only depends on xSS Reason is based on doing security analysis as it removes some circular logic. Question when ServerConfiguaration is sent (SPT - Sean Turner) - It is optional and fails goal of making entire sequence of items known based on server & client hello. Question on absolute time vs relative time: (Ian@google) Could a configuration be delivered because local clock is skewed? EKR - problem with relative time is that need to adjust at all times, absolute time will have a fixed stop point. Like in Quic there is a clean fallback if the configuration is rejected. Question on what early data w/o early handshake (DKG - Daniel Kahn-Gilmor) - No client auth Should rename things DKG - Sugest that skipping over items (ceritifcate, verifi, app data) could be in a single message and skip forward. This deals with case of server cannot make the pre-existing shared key on a 0-RTT handshake MT (Martin Thomson) - Thought this was how things were going to be - Can put multiple messages in a single handshake record. EKR- Cannot see into the handshake message - so does not work - can be other things. Question if the size or temperal sequence are issues in creating the first ClientHello message. DKG -Doing the API is a problem if you do not make the 0-RTT appliation data as part of the first function call. This implies that you know the initial data size. Problem is that forward security properties in the middle of the stream w/o the user knowing when it happens. MT - Perhaps should just not do encrypted content type - only protects the transistion from non-PFS to PFS. If that is the issue - then sending app data may not be a good idea anyway. MT - Number of things in the handshake which are optional - can we reudce the number of options. Expect that we are optimizing for a case which is going away. Move from RSA to ECDSA cheapings the cost of signing. DKG - Suggesting removeal of * on the Cert and Cert Verify server side messages. SF (Stephen Farrell) - Question on checking about IoT world - does this affect them much? MT - Mostly using PSK modes so less affecting of them. EriK Nygren - Worry about the computational cost for mobile devices - this change would affect them. DKG & EKR- looking at strawman for Extensions are the server offered rather than client suggested. Group of configuration data is going to provide some crypto configuration. Question on clear text vs encrypted content of extensions - EKR thinks it should only be clear. MT - Sould not need to have the signature - as it is going to be in client hello anyway? EKR - will flesh this out MT - Looking for positive statement of rejection of 0-RTT data. EKR - response - why would a client offer identity on the resume if not on the first session? DKG - what about a resume due to ask for identity info from the server to client. EKR - need to have the server be able to say that it is expected in the configuration data. AP (Andrei Popov) - May need different credentials depending on where one goes from a landing page - need to do this for either add identity to current connection or push to a new connection - and needs to have the client push identification data correctly. MT - If you allow for PSK + certificate authentication for the client - you also need to allow it for the server and that becomes hairy very fast. MT - Ignored problem earlier - inheritly bind cipher suite to the PSK. EKR - Problem with ugrading cipher suites in the field w/o upgrading keys. Only an issue with the KDF not with the symmetric key. *** Andrei - TLS 1.3 CLient Auth YN (Yoav Nir): HTTPS 2 does not allow this pattern of inline either. AP: Some sites will stay and not upgrade (unknown): couple of ways even in HTTP2 to get certificates - including "go back to 1.1 to do this" Stephen Farrel - Questionss about WebDav - does it need it? EKR - on interleaving - server must stop sending data after asking for a cert. MT - worried that avoiding ungliness in HTTP by introducing it into TLS. Server should not be sending resource data until authentication done. So no need to not interleave. DKG - If interleaved sessions - what resource is the negotation being done for? Session #2 **** EKR Status starting w/ AEAD IV Traffic Key Generation question - Ask for sense of the room on doing this MSJ (Mike St Johns) - Biggest attck is from HMAC - EKR - Why does not key length fix that MSJ - maybe it does - still issue of strong vs weak EKR - Usage labels are devided in to interior and exterior keys. Extererio list is explicit, interior keys are the rest. * EKR Will look at the two current proposals and go forward with this. Signatures w/ known configuartion - question for objections Nobody in the room stood up to object, several people said it should be done. EKR will write it up and send to the list for other objectors. SF - raised question on what parallel means for signature amortization EKR - think about in parellel - write in serial Chair Humm on the always sign issue - rough consinsus for always sign 0-RTT Failure Recovery ?? - Is there a server resource problem with the decryption time EKR - Don't believe it is a real concern MT -Agree w/ cost being low concern A La Carte Cipher Suites MT - Need to consider the anonymous modes as well - Key exchange, AEAD, hash Joe - would prefer to see everything negotiated together. EKR - Signature on the server side is independent - client indicates no signature by not sending data. RS (Rich Salz) - This is bad for consumers to try and use - current is bad enough DKG - Most people freak out on one part of list - People say don't want to do PSK rather than just one cipher suite. YN - confusing story of users and protocol. These do not need to have the same presentation EKR - summary - think people either do not want to change or make very minimal changes DKG- do think signature should split out MT - Authentication mode may need to be dealt with as a separate issue, needs to be agreeed on. Presentation of things is oing to be based on what the provider supplies. Different vendors do differentthings Humm - should we kill off the ala carte menu options? Split of the room on this. So will entertain proposals. *** TLS Traffic Padding - DKG YS - This ability has been in IPSEC for alot of time -but has not been used much DKG - I have a concrete case today for using this. And it is not clear that historically poeple have understood the problem with it. YN - Can this be used to do zero length application data to hide user timing issues DKG - Yes it can. DKG and EKR - Discussion of issue on where the padding occurs in handshake messages and how the MACs are computed in terms of where things exist. NSS does not have problem with this as the padding is done at a very low level. MT - Issue dealing with minimum padding issues - People have requested ability to have down to one byte of padding. This is not in current proposal. DKG - Seems hard to say that if you are padding, you need some type of "minimal" padding. Push 127 to 256 rather than 128 seems to be ok EKR - Padding question - PR #147 - question on including things in the session hash computation Quynh Dang - Suggest that padding be done in a new scheme - zeros followed by 1 instead of the TLV EKR - no real problems - small problem with doing the scanning 4492bis - no slides - YN SPT - Ask for reviews on this draft to get it up to EC on std track SPT Will check with the CFRG that 25519 and goldilocks are stable and go foward EKR - What about brainpool- can these code points be put here as well. Want only one document to look at for code points Humm - High desire to omit brainpool curves - small hum on no - bigger hum on yes. Room concensus is yes. *** dnssec-chain-extension - Richard Barnes PHB (Phillip Hallam-Baker) - Asking if this should be experimental - don't want to make ICANN as a trust provider who is privleged EKR -Why and extesion and not a new certificate type? DKG - want it to be coroberative thing not an either/or Many arguements over where and how the DNS records should be placed. HUMM for question on adoption - more pro than con - will go to the list *** ETSI and IEEE certificate formats EKR - are the certifictes isomoriphic between the different formats? Any chance the IEEE and ETSI formats are going to be merged. Spt - there is a third one as well - SPT - Question from plenary about butterfly algorithm SPT - Procedural question - is this to be a working group item? Request for feedback prior to thinking about adoption ** TLS Session Key Interface Issues raised in the room - RSA as an oracle, What is the Edge server authentiation method, other designs that have done this *** ECDHE_PSK for AES-GCM and AES-CCM EKR - Yes and 1.3 has removed all these cipher suites Dan Harkins - should specify the hash size as well for this Issue on key randomness should be a security consideration EKR - we should have question of how algorithms should be done and how completeness for suites is going to be done. *** Quantum safe hybrid cipher suites MT - Why not just do a new key exchange method? MT - Pushing in a number of key exchange methods under a single identifier is problimatic. Should look to CFRG to get some review on both this and authentication Tanya & DKG - both think the hyred is good DKG -why not make it an extesnion to add quantim safe