TLS Working Group IETF 94 - Yokahama Day 1: Wednesday, November 4, 2015 09:00-11:30 (JST) 0900-0910 Chairs Administrivia 0910-0920 Yoav RFC 4492bis Yoav presented the status of RFC 4492bis Slides are at https://www.ietf.org/proceedings/94/slides/slides-94-tls-0.pdf If no objects for pull request #10 then is going to be merged EKR requested a PR for the TLS 1.3 draft that does the same thing as PR #11 For pull request #13 - Yoav believes that Expert Review might be better than Specification required. EKR trade off between too many algorithms showing up and hard to get the needed algorithms. Mor of an issue for algorithms than curves perhaps. Russ suggests that a small section for experimentation should be done - EKR does not object to this idea. There are issues that need to be dealt with in that experiments that work will not want to change numbers and will squat on experimental code points. STF - Policy needs to be on all of the registries not just the curve A policy is designed on the fly for dealing with 16-bit registries. Partitions the space into multiple spaces with a tag of good/perhaps/bad for things that come out in the wild. Policy is designed to slow down the consumption of the space not to prevent registration. Still need to write the guidence for the Expert review. EKR suggesting a superficial review at most. 0920-0950 EKR TLS 1.3 Since Prague Slides are https://www.ietf.org/proceedings/94/slides/slides-94-tls-5.pdf Client certificate request discussion: DKG: there are some questions about privacy leaking whendoing a certificate request syntax as things like UI will provide timing information. EKR: Yes this is an issues - if you have mitigation please help. Text on the issue for the document would also be nicee. Post-Handshake Authentication: YN: What data is needed to keep to have the context EKR: Keep the hashes for the acceptable algorithms when it supports. DKG: Whyis the server certificate in the 0-RTT - problem with making sure you are talking to the right entity. EKR: Might be possible to use SNI instead, but need to do more careful analysis. Need to deal with wild card certificates among other issues. Server may not need to respect the SNI value, it is included in the hash from the hello. MT: Design was to ensure that SNI was validate by the server. EKR: Also need to digest in for key extensions of certificate. Comments on data flow picture: 1. Appliction data should be covered by 0-RTT 2. Should have optional application data immediately following server finish Framing for 0-RTT: R Satz: please use alert for close..notify HelloRetryRequest: Doing the address token might make DTLS easier. Need to try and avoid some trial decryption Also, if cookie is re-usable then need to have some expiration markers or algorithm. This needs to look at the client correlation properties as well. Re-Keying: Need to figure out what the saftey margin needs to be, there needs to be a discussion on this. Then need to look at what the attack model is going to be. This is different for TLS and DTLS as a single decrypt alerts or TLS but not DTLS MT: Rekeying is a trival things to implement an allows one to be as conservative as one needs to be. EKR: Second benefit is forward secrity as all data before the crank of keys is not reachable. AP: Like mechanism because it is easier. Should there be a way to force the opposite side or just drop the connection with an alert. Brian Ford: Need to look at re-key loops. Poll of room: We should just do this and not worry about the step of getting a response from CFRG. Exporters: People are asked to determine if the fact that the client certificate is not included in the exporter secret is an issue. Usages of exporters are 1) get secondary keys 2) channel binding type things. BF: Could it be a method of forcing export key to be updated is done. EKR: Yuck AOB: SPT: Requests for additional ciphers from others. Listing in A.4 Suggest thinning it down to the SHOULD/MUST list only. EKR: Need to encourage support for PSK variants EKR: Looking at the difference between the "good" list and the "safe" list and the "no opinion" list EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is good. SPT: Did we settle on the SHA-1? MT: Way for client to signal that it did not want sha-1. What is valid for the cert chain. PSS: slides: https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf Russ: Are you trying to encourage poeple to move to PSS or to ECC? SPT: Numbers of affected people are going to be in the double digits for adopting PSS (old slide) RS: Likes the question raised by Russ - has an obvious opinion. EKR: Can deploy and then turn off v1.5 later based on numbers Ian S: What can we do to compress the certificate. Offer option of doing hash of certificate EKR: Caching certificate extension should solve this Keyless-SSL: Slides: https://www.ietf.org/proceedings/94/slides/slides-94-tls-6.pdf MT: Where do you see this being deployed? RB: Don't believe that this is really the correct working group for it. No protocol mods for TLS. Suggest a BOF on this topic. DM: Asking for feedback at the moment. DKG: There are places where remote key presence is high desired. Not limited to TLS. DM: API can be very close to the HTM API. RS: Want to make sure you don't become a signing oracle. Might be some IPR on a related version. Day 2: Thursday, November 5, 2015 17:40-18:40 Solve the SHA-1 Question - Martin Thompson slides: https://www.ietf.org/proceedings/94/slides/slides-94-tls-7.pdf Rehashing some of the discussion from the mailings list. Problems with root certificates, problems with re-use of same material Root certificates/Trust anchors should not care about the algorithm as it is just a key container. Trust needs to be checked else where. RH: need to know the name of a trust anchor as well. Signature is not important Room Poll - no objections to this approach - solid yes hum YN: Should not make protocol statements on what the client should accept - Feels to be wrong approach. EKR: The behavior of signature_algorithms has been defined since the start. We are just talking about removing the restrictoin for one case. 1805-1830 DKG/EKR SNI Encryption slides: https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.pdf YN: Question on why for example on page 5 the cover certificate is not enough DKG: Want to generally have one mechanism - EKR: Might be able to make the co-tennanted flow accept 0-RTT data, but no the other case MT: Why are the encrypted extensions sent through? There are two keys that are in play - a 0-RTT key fo the gateway and the hidden server's separate keys EKR: Mistake in the diagram on 7 - the hidden server should claim it does not do 0-RR and fail Hidden server must always send a 0-RTT data that corresponds to the gateway state, not it's own state EKR: For the shared point, the only new thing is the one extension For the gateway case there are more semantics that need to be dealt with DB: Would it not be easier to do a tunnel protocol? DKG: That would require that the gateway actually do cyptographic work - there is no additional decryption by the gateway in this case. It is just packet forwarded. EKR: Somewhat convinced by Bev's case - we placing trust in the gateway for somethings - additionally request of doing the decyption may not be that hard. RS: Slides and presentation may not be helping understanding here. Need to look at things outside of protocol as well. Think this is good to do. Mike Bishop: Requirement to do encryption by the gateway may indeed be an issue base on feedback from http workshop. MT: Can put in the encryption extenstion for RSNI - may be enough to bootstrap. 1830-1840 Jay TLS/DTLS PSK Identity Extension slides: https://www.ietf.org/proceedings/94/slides/slides-94-tls-1.pdf Did not get presented.