Notes taken by Stuart Cheshire ------------------ UTA WG @IETF 89, London FRIDAY, March 7, 2014 0900-1130 GMT Friday Morning Session I Richmond/Chelsea/Tower APP uta Using TLS in Applications Leif Johansson Orit Levin -------------------- 09:00 Welcome by chairs, getting organized, discussion Goal: Improve security, while making no changes to TLS or the popular TLS libraries, and minimal changes to the applications using TLS. [Discussion of Deliverables; Slide 8] Keith Moore: Threat analysis document should not be limited to just poor use of TLS. Scope should be TLS threats in general. Leif Johansson: We're not proposing changing the charter here. Keith Moore: Improving security is a good goal. Looking for commonality between how TLS is used in various applications is not useful. A checklist of things to know about TLS could be useful; another document that people have to read would not. Aaron Kaplan: I'm one of the co-authors of the BetterCrypto.org paper. There was lots of discussion of how to get the best cypher string. I should document that. Leif Johansson: That would be very useful. Stephen Farrell: Don't block on deliverable 1; keep 2 short; make sure 4 is not TLS-specific. Daniel Kahn Gillmor: I think it *is* useful to identify commonalities. Are there patterns we tend to see? Expectations for SMTP are different from HTTP. We could group protocols into three or four profiles. Keith Moore: Let's not block on that either. Franck Martin: It would be interesting to differentiate between SMTP-submission and SMTP between MTAs as categories as it seems so far documents in the agenda tends to handle the former and both are slightly different in implementation. -------------------- 09:17 Applicability to a generic application XMPP over TLS Peter Saint-Andre Olle Johansson: The XMPP document is a good template for other protcols. SIP come to my mind. Yaron Sheffer: To clarify, the TLS 1.2 cipher suites are not just because they're new and shiny. It's because unfortunately TLS 1.0/1.1 cipher suites are generally broken in several ways. Leif Johansson: Should we pursue this approach? Stephen Farrell: I think this is a good approach. I don't know what to do about earlier versions of TLS and cipher suites. Don't do those things, but if you do... Don't know if this is a rat-hole. Peter Saint-Andre: For my own XMPP server I can only have OpenSSL 0.9.8. Guidance for people in similar situations would be helpful. Stephen Farrell: The BCP document should concentrate on the Best CURRENT Practice. Old practices can go on a wiki page. Dan York: I like the idea of using the XMPP document as a template. Daniel Kahn Gillmor: We're not modifying TLS or application layers, but we want to be able to prevent fallbacks to older versions. Something like HTTP's STS could help. Client can signal things like "For this server I require TLS 1.2 or better" Once a client sees a servers supports TLS 1.2, it then requires it. Can cause problems for server farms where not all servers in the farm are upgraded at the same time. Still, would be good to have an STS-style protocol ratchet, that never falls back. SSL strip is an "attack" on how TLS is used by HTTP. We need to document these sort of things, like insecure renegotiation. Peter Saint-Andre: Don't we have an RFC on the renegotiation attack? Orit Levin: I think this is a good suggestion. Please contribute to the document. Daniel Kahn Gillmor: I'd be happy to. Leif Johansson: I want to hold you to that. Kohei Kasamatsu: Attack against PKCS 1.5. I don't know whether we solved it. Leif Johansson: Could you write a few lines of text for the list? Kohei Kasamatsu: Okay. Leif Johansson: Thank you. Peter Saint-Andre: This document represents a "slice in time". Leif Johansson: We're not committing to producing an IANA registry of known attacks against TLS. (Which sounds both scary and plausible.) Eliot Lear: I like the document organization. We should focus more on the pedestrian issues surrounding ways new applications be should using TLS and TLS certs. The XMPP doc gives specific directions. Would you do the same for other applications? Peter Saint-Andre: RFC 6120 references RFC 6125 about cert verification and validation. Are you talking about that? Eliot Lear: No, attributes within certs. RFC 3920 for instance. Would you do it the same way for other new applications? Orit Levin: Which document are you talking about? Eliot Lear: The BCP. Chris Newman: The StartTLS attack should go in the attacks document too. I will write text for that. Leif Johansson: Should we adopt as WG documents? Peter Saint-Andre: The attacks document is incomplete. Barry Leiba: If the WG is working on this document, it should be a WG document. It doesn't need to be finished already. Leif Johansson called for hum for adopting "attacks" draft - No hum against - Loud hum in support Leif Johansson called for hum for adopting other two drafts (framework and XMPP) - No hum against - Loud hum in support -------------------- 09:39 Prohibiting RC4, Orit Levin on behalf of Andrei Popov RC4 is high performance and immune to BEAST attack. Remains very popular, though it has known weaknesses. Microsoft reports that 40% of communication attempts failed when RC4 had been disabled on clients. Keith Moore: Long-term this seems like the right answer. In the short term, given the widespread support of RC4, it's not. Even if RC4 is flawed, it is still better than plaintext. Instead of deprecating RC4, is it possible improve RC4 to remove its known weaknesses? Stephen Farrell: In this community, no, we don't know any way to improve RC4. The recommendations are good, but should not delay the BCP. Consider the Kerberos DES die-die-die document, which took years. Negative recommendations would delay the RFC a lot. Ted Hardie: I agree with Stephen Farrell. FWIW, RC4 will not be present in TLS 1.3. A note about avoiding RC4 would be a good thing for the wiki. When 40% of web servers support only RC4, switching them to cleartext instead would be worse. Deprecating cipher suites is appropriate for a new TLS version number. Recommending against their use is appropriate for a wiki. Orit Levin: We are not advocating cleartext. We are advocating moving to something *better* than RC4. Aaron Kaplan: We discussed this in the BetterCrypto project. 15% of Mozilla users (in China, India, etc.) use Windows XP, and have only RC4. Perhaps web servers could detect clients using RC4 and direct them to a landing page that tells them how to update. Daniel Stenberg: I'm the primary author of curl. With our users, we find only a small percentage using RC4. Keith Moore: For new applications, prohibit RC4. Orit Levin: Working Group charter is focused on existing applications, not new ones. Rich Salz: Draft is too broad. With TLS 1.0, RC4 is the best you've got. For TLS 1.1 and later, don't use RC4. Leif Johansson: This should remain a separate document of its own. Pete Resnick: What are we putting in these documents? Will putting "MUST NOT"s in the BCP document slow it down or not? What decides what goes into the BCP document and what goes into the attacks document? Leif Johansson: The attacks go into the attacks document. What to do about them goes into the BCP document. In this case, the attack is "RC4 is weak", which goes in the attacks document. What to do about it is "use something better than RC4", which goes in the BCP. Eric Rescorla: What is new is not that RC4 is weak. We know that. What is new is there's now a practical attack against RC4 in the web context. That's what makes it serious. Pete Resnick: All of this should go in the attacks document. Having this WG try to work out attack mitigations would worry me. Leif Johansson: We should remove attack descriptions from BCP, and move to attacks document. Recommendation to deprecate RC4 should remain a separate document. The TLS WG could take on that work. Orit Levin: We should make different recommendations for different TLS versions. Yoav Nir: I don't believe 40% of servers only implement RC4. 40% of servers have been *configured* to only support RC4, but their libraries support other algorithms too. Administrators have selected RC4 because it's immune to BEAST. Now that browsers have BEAST mitigations, AES-CBC is a better choice than RC4. In many cases can be fixed just by changing configuration. The main BCP document should make no negative recommendations, only positive recommendations. Franck Martin: It seems to me that when doing opportunistic SMTP+TLS the weakest cipher is picked, so instead of not recommending RC4, why don't we recommend to choose the strongest cipher, while defining strongest is a difficulty. Yaron Sheffer: The RC4 attacks are already mentioned in the Attack doc. OTOH the RC4 recommendation is in my opinion too extreme for the BCP. Stephen Farrell: Agree that BCP should be positive recommendations. Sean Turner: We have a track record for how to deprecate cipher suites. Chris Newman: This is the wrong recommendation to put in an application-oriented BCP. We could say something useful about RC4 in a BCP. Peter Saint-Andre: When we know something is bad, we should say so. Don't just talk about the good stuff. Keith Moore: Don't block on saying bad things, if the bad things will take longer. Orit Levin: Positive recommendations are educational. Stuart Cheshire: Would like to see guidance for *new* apps, not just guidance on workarounds and mitigations for old apps. Otherwise, *new* apps are likely to make the same mistakes, and then need workarounds and mitigations for those mistakes. Orit Levin: This for the Area Director to decide. Peter Saint-Andre: Negative recommendations are fine. RFC 6176 says "Don't use SSLv2" and has IETF consensus. Referencing such things won't slow us down. Yoav Nir: Why are you picking on RC4? Why not say "don't use Single DES"? Peter Saint-Andre: Let's remove things we don't have IETF consensus on (like this RC4 text). For things we do have IETF consensus on (like RFC 6176) we should include that guidance. Yoav Nir: We have an RFC about Single DES. Peter Saint-Andre: Great! Send text. Eliot Lear: When we talk about MD2 or DES, that's like telling people to remember to tie their shoelaces. The RC4 recommendation should be made, but not here. Leif Johansson called for hum for moving specifics of RC4 attacks to attacks draft, keeping rest as separate draft. - No hum against - Substantial hum in support Andrei will supply text for the attacks draft. -------------------- 10:10 TLS certificates for email, Alexey Melnikov Matthew Miller: We are discussing the CNAME stuff in DANE. Alexey Melnikov: These documents pre-date DANE. Matthew Miller: Right, we should talk, and synchronize. Joe Hildebrand: Is there a DBOUND interaction? Alexey Melnikov: Good question. Don't know. Matthew Miller: With SRV ID, CAs have been resistant. Can we work with CAs to make this deployable? Alexey Melnikov: It's implemented in our mini-CA, but no one except us uses it. It's possible to access this in OpenSSL. Leif Johansson: Where do you want to go with this? Alexey Melnikov: I have talked with Keith Moore and Chris Newman and we can fold it into their document. You asked if this applies to other protocols. There are differences with XMPP, for example. For now it's email-specific. Peter Saint-Andre: This applies RFC 6125 to email. Is this talking about TLS for email? PKIX for email? This is good stuff. I just don't know where it belongs. Orit Levin: We'll take that discussion to the list. Chris Newman: RFC 6125 is about using PKIX in applications. This is binding that document to email protocols. We can keep two separate documents, or merge them. Joe Hildebrand: If we decide we want to update RFC 6125, there are a good group of people here who can do that. -------------------- 10:20 E-mail over TLS, Chris Newman Focus is MUAs for IMAP, POP and Submission. Port 465 was briefly assigned for SMTPS (use of TLS is implicit) but then abandoned because all MTA traffic has to use port 25 (where TLS encryption enabled by the STARTTLS command). SMTPS doesn't make sense. Port 465 is still frequently misused for mail submission, (where implicit TLS does make sense) but port 465 is officially registered for "URL Rendezvous [sic] Directory for SSM" [Toerless_Eckert]. Proposal to officially register port 465 for dual use. Alexey Melnikov: TSVWG is discussing port use. This should be raised there. Leif Johansson: Who should we talk with? Alexey Melnikov: Talk with Joe Touch. Dual registration is not currently allowed. IESG would have to approve a one-time exception. Stephen Farrell: IETF consensus beats opinion of ports experts. Chris Newman: Still doesn't hurt to discuss the issue. Eliot Lear: Is this a good idea? Why is this an issue we need solve? Chris Newman: Too many existing clients already use port 465, and are unlikely to change. If we register a new port, we'll have two ports for the same function, and interoperability problems. We could disallow implicit TLS, and that would be ignored too, and would create more interoperability problems. Alexey Melnikov: Several big ISPs including Gmail use port 465. Port 587 is also widely used. Pete Resnick: We don't have the right people in this room to make this decision. I worry we won't know how to distinguish secure submission from secure SMTP relaying. Will we need a STARTSUBMIT command as well as STARTTLS? Dual registration of a port is really worrying me. Barry Leiba: IETF consensus may beat opinion of ports experts, but IESG still needs to approve it, and if a document which makes statements about ports goes to the IESG, the IESG will naturally consult the port experts. Chris Newman: I'm curious to hear about who has deployment experience with RFC 6186 "Use of SRV Records for Locating Email Submission/Access Services" because it affects how certificates are validated. If there's no deployment experience and no intention of deploying that then maybe we can simplify our proposal. I welcome feedback on that. Eric Rescorla: I'd like to hear the security proposal for chaining from what I started with to what I ended up with. Maybe this is a DANE question? Chris Newman: That RFC specifies how the SRV ID is used. Stuart Cheshire: It's for automating email account setup, the way SRV records are intended to be used. Eric Rescorla: No information I depend on can be in the DNS, unless we have DNSSEC? Chris Newman: See RFC 6186 Security Considerations. Keith Moore: It makes the email clients more complicated. It affects how clients have to check subject alt name on server certs. It would be nice if we didn't have to include all that detail. Eric Rescorla: I'm concerned about these delegation mechanisms that implicitly assume that DNSSEC works. Joe Hildebrand: I just sent a note to the person that registered 465/tcp with my IAB hat on. He works for my company, and we know each other, so hopefully he'll respond to me. Peter Saint-Andre: Thanks, Joe! Joe Hildebrand: Best outcome would be the current registry to be voluntarily retracted, so we can use it. Chris Newman: Open issue is: DANE for submission; the DANE SMTP draft is using DANE for SMTP relay. There's a mess in SMTP relay; DANE is a plausible way to clean that up. I've been asked to put DANE for MUAs in this document. Should it be a MAY or a SHOULD. Stuart Cheshire: We should check how clients trust the SRV data. Chris Newman: RFC 6186 says clients should check the SRV ID. Chris Newman: Next open issue: Cipher suites. Draft-00 had a bunch of cipher suites recommendations. Draft-01 removed most of them. Should I say more about cipher suites in this document? Would anyone object to me leaving cipher suite recommendations to the BCP document? Keith Moore: If there are things that are unique to email that would affect the advice in the BCP, you should detail that out. Leif Johansson: Is it possible for you to take what you have now and move it closer to the outline that Peter has indicated? Chris Newman: I'll take that as an action item. Leif Johansson: Do one more rev of the document and then we'll consider the Working Group adoption question. Keith Moore: I don't get that. Working Group adoption doesn't mean the document has to be finished. Leif Johansson: It might be easier to make changes before the doc is adopted. Keith Moore: We'll keep editing this document Aaron Kaplan: We don't know what ciphers may be broken in the future. Such issues are unlikely to be email-specific. It's easiest if we have just one document to update. Next issue: Upward security latches. Provisional vs. Normal. What happens if cipher suite with PFS is found to be flawed and must be disabled, resulting in failure of PFS latch? Eric Rescorla: What is the benefit of the PFS latch? TLS has a negotiation mechanism and a protection mechanism for that negotiation. Under what circumstances would a server be unwilling to use PFS? Chris Newman: What if a server is swapped for a server from another vendor, which doesn't support PFS? Do we want that change to happen silently? Eric Rescorla: That's an operational decision for the administrator. It doesn't need to be in the protocol. It's not analogous to HSTS in HTTP. Chris Newman: So, we can drop this latch, but this would be a great discussion to have on the mailing list. Eric Rescorla: I'm happy to have this discussion on the mailing list. Tero Kivinen: I think latches are not useful. They will just generate support calls. Chris Newman: The current situation is that if TLS changes to plaintext, clients will not complain. Tero Kivinen: That's the only latch I think is useful. Keith Moore: The latches are for two purposes: 1. To thwart downgrade attacks, particularly downgrade to plaintext. 2. To make users aware when security of connection has changed negatively. We could handle those two cases differently. Daniel Kahn Gillmor: TLS 1.3 will most likely have only PFS ciphers. Chris Newman: So I could replace the PFS latch with a TLS 1.3 latch? Chris Bentzel: Are you looking at Signaling Cipher Suite Value (SCSV) instead of latches? Chris Newman: I have not looked at that. Please send text to mailing list. Eric Rescorla: To recap: If you complete the TLS handshake you have protection against all forms of downgrade attack. There are two forms of downgrade attack possible: 1. Not being a TLS server at all. 2. Simulating being a broken TLS server. In case 1 a latch helps. In case 2 it might help. Perhaps. Chris Newman: So we probably don't need the PFS or TLS version latches. William Chan: SCSV is server-validated. A malicious server would ignore SCSV. Chris Newman: So the TLS version latch might be useful. Stuart Cheshire: To be clear, when we inform the user of a downgrade attack, they read that as, "Mumble, something security, press the blue button to continue." Chris Newman: Should we encourage use of unauthenticated TLS? -------------------- 10:58 Summary from STRINT, Stephen Kent, BBN Technologies See the last slide in the “chairs deck”. Keith Moore: Active attacks are becoming increasingly prevalent. Merely preventing passive attacks may have little value in today's world. Stephen Kent: The experts attending STRINT felt that passive attacks remain a threat worth addressing. Keith Moore: I'd like to see hard data on the exact amount of covert surveillance being performed via passive monitoring compared to the exact amount of covert surveillance being performed via active monitoring. Stephen Farrell: We should think about how this affects opportunistic keying. Joe Hildebrand: We don't need to continue to try to be so accommodating to middleboxes. Keith Moore: This is not a solved problem. Some middleboxes drop or corrupt TCP segments that use MPTCP options. Stephen Kent: Banks should still be using server-authenticated TLS with Extended Validation certificates for sensitive transactions. Keith Moore: What's an example of something that's not sensitive? Steve Kent: Public Facebook postings, perhaps? -------------------- 11:10 Opportunistic Encryption Using TLS presented by Joe Hildebrand for Paul Hoffman Derek Atkins: Failure to achieve opportunistic encryption could be treated like getting a TCP RST. Could log the reason why, but should not offer the option to continue. Ted Hardie: Need to distinguish between authenticated keys, Trust On First Use (TOFU) keys, keys with an expected lifetime, and truly ephemeral keys. Daniel Kahn Gillmor: When we're talking about "users", remember that not everything has a human user in front of the screen. If we have no UI for other related things, then we should have no UI for when a long-term key changes. User may have no long-term key at all. Franck Martin: I think this is wrongly worded. Can't hide encryption state of connection from the user or the application, because it will be visible in the email headers. Derek Atkins: Opportunistic encryption only protects against passive attacks. Discussing active attacks against opportunistic encryption is self-contradictory. Ted Hardie: TOFU is one ratchet up from purely opportunistic encryption. Keith Moore: The slide mis-states the problem. We shouldn't assume that all users are stupid. There are use cases for opportunistic encryption. Stephen Farrell: These definitions and concepts should be broader than just TLS. Joe Salowey: Opportunistic encryption is for everyone's good. If you feel under attack, you need something stronger. Jeff Hodges: Maybe dealing with pervasive monitoring at the app layer is just the wrong place to do it. Rob Trace: People in the room should not forget that in HTTP the scheme implies much beyond just the networking properties. Resources may be cached and come from a variety of sources, some opportunistically encrypted and some not. Ted Hardie (with IAB hat on): Do not block this work waiting for the IAB to ack, but feel free to contact the IAB. Pete Resnick: Work in partnership with IAB; do not block on IAB. Daniel Kahn Gillmor: Users are not stupid, but they may be ignorant of whether there is an active security attack underway. With respect to HTTP, opportunistically encrypted data should be presented as the same as cleartext. Orit Levin: We currently have no draft relating to HTTP. Maybe we should have one? Rich Salz: Why no mention of HTTP/2.0? Stephen Farrell: HTTP/2.0 work is ongoing. That work should not be delayed by what we do here, and what we do here should not be delayed by what is going on there. -------------------- END