TLS Working Group Meeting IETF-89, London Tuesday, March 4th, 2014, 1610-1840 Chairs: Eric Rescorla, Joe Salowey Notes: Matt Miller Version: 1.1 -------------------------------------------------- BL == Ben Laurie JS == Joe Saloway EKR == Eric Rescorla SK == Stephen Ken DM == Daniel (Migault?) YN == Yoav Nir KP == Kenny Paterson MSJ == Mike St. Johns TK == Tero Kivinen RH == Russ Housley MT == Martin Thomson PH == Paul Hoffman DMcG == David McGrew ST == Sean Turner CJ == Cullen Jennings DA == Derek Atkins MNOT == Mark Nottingham DKG == Daniel Kahn Gilmore MP == Max Pritikin MJ == Mike Jones PMcM == Patrick McManus 1. Administrivia (5 Min) - Note Taker, Jabber, Blue Sheets 2. MAC Ordering (15min) Presented by Eric Rescorla - draft-ietf-tls-encrypt-then-mac No comments in room. Next Steps: Draft to be submitted as working group item, review then WGLC 3. Downgrade Protection (20 Min) Presented by Ben Laurie - draft-moeller-tls-downgrade-scsv BL: reports approach has been deployed in chrome 33 without problem. ACTIONS: * The Chairs believe this is something the WG wants, so will approach the ADs about adding it to the charter. DKG: It was not clear if there was a resolution to if an extension caused an extension to fail or otherwise. BL: I think if it something systematic then you'd find a way to fix the software. 4. ChaCha Ciphers (10 Min) - draft-mavrogiannopoulos-chacha-tls KP: Both of these algorithms (chacha and poly1305) have had significant review, but not enough that you would probably be comfortable with for TLS. EKR: YN: Google's servers are using it in their software (Chrome to Google servers, about 2%). It's treated as a stream cipher but it's more like a ctr-block cipher. JS: We need to discuss if we are taking the correct approach; it's being used as a stream cipher where maybe it should be used as a AEAD. JS: We need more review before we can ask for adoption. 5. IVs, DTLS, ChaCHa (10 min) Presented by Kent EKR: The two arguments for not using the IV like this is because you save 8 octets each packet, and it's not known what the security guarantees are while we do with explicit IVs. Rather, do you know what the warning labels are for this? SK: I need to go back and look. I know NIST has something about how to use counter mode safely, but I don't remember off-hand. EKR: This is something that we could use guidance for. DM: Can we also define an IV generator function, that could take into account a counter? SK: No (-: The idea from an eval perspective, you can submit the stamp that says "I have used these algs in these modes". MSJ: That's for the encrypt side, but you decrypt with what you're given (before we got fancier with AEAD). EKR: Note this is about helping you not screw up. TK: Make it so you can get the seq num form the IV as output from the cipher. SK: You should definitely take that to the list! 6. CFRG Update (15 Min) Presented by McGrew PH: I did not hear only one new curve family, but a limited number. I don't know if one is a good way of going forward. DmG: I do think we need to limit the scope. PH: I don't think the room felt one was the right number, but we definitely don't want a lot of others. McG: Its particularly true if some of these can't be used for some things like signatures. PH: I don't want us to focus on one, but we don't need to be really generic. EKR: As a consumer, the primary motivations are performance and the security over the NIST curves. So what I think we want is one extra set of curves (ECDH and ECDSA) at the necessary security levels (e.g. 256, 384, 512). Unless there's very strong evidence for radically better properties, we should not have more than one family. McG: So, something like Brainpool that doesn't require a code change, or would it be ok for something that is better but requires different code. EKR: If brain pool is acceptable that is something we have a standard for DMcG: and there's a category where it needs to be interoperable with existing code. RH: That is one of the points I stood up to make. We really ought to consider that the interoperability point is important for the consideration. RH: Note that it is early April, and there's certain requirements for notice on interim meetings, so you should post something to the list very soon. ST: avoid crypto sport, limit to one or a small number ACTIONS: * Chairs agree that having a cross-WG teleconference is worthwhile; to announce on TLS mailing list to meet IETF virtual interim requirements 7. Session Resumption Issues (15 Min) Presented by Karthik Bhargavan ACTIONS: * Recommend others read these drafts and comment on lists Stephan S: One of the problems that I run into, it needs to be unique and it needs to be available to the auth layer. If it's not integrated into the TLS stack then I can't use it. Why do we have to go through all of this if we already have good data for the session identifier. KB: The only problem we have to deal with is what happens if the server certificate changes. SS: If both the 'm' server and the real server have the same certificate then the CA system is broken. KB: Sure, but if you have another handshake that uses the different certificate than the initial handshake. SS: I'm not sure what you're trying to solve, but you need to verify the certificates. DG:There is another approach is if you want to hide your SNI, which you do by negotiating without SNI then re-negotiate with SNI (and changing your cert). DB: Also, if the server is using a known good list then you avoid a class of problems. PSA (MRex): I'm not aware of implementations that can get their hands on the master secret. KB: There are APIs for you to get the master secret within the TLS, but don't necessarily let you get it outside. Kenny Paterson: And someone could go into the software and parse out the master secret. KB: We should not that we're not saying you pass up the master secret, but by chaining together the final messages you get the best security. 8. TLS 1.3 (60min) - New protocol flows - Requirements: do we need - Encrypted SNI? - Static RSA? - Resumption? - Record layer issues - Cipher suites - Version number - MAC/Encrypt order BL: Why is the ServerKeyExchange not encrypted? EKR: You could do that BL: I think you should RH: If I understand this right, you are doing two DH (EKR: Correct). Is the cost for the additional DH is less than the first half. EKR: The speed of light is not getting any faster RH: Note the cost is pretty significant. EKR: I'm trying to say, not you must do this, but rather you can do this if you want encrypted SNI, but you have to pay the cost. We need to decide whether this benefit is worth paying that cost. MT: If the server is sending the message, it has to be evaluated by the client, which means the client needs to wipe the message before doing anything else, which means we have two round-trips. PH: If the server's key is ephemeral, there could be two or more of them? How does the client tell the server which key it's using? EKR: There is a label, in the PredictedParameters PH: So how is this managed? Because we don't have a slot for this in DANE. Daniel Kahn Gilmore: If we make this too long, it can be fingerprinted. EKR: I think we deliver this encrypted, so it's possible for the server to deliver a new one each time. DG: There are two ways to do fingerprinting: fingerprinting the client, and fingerprinting the server. EKR: I'm concerned about the second one. DG: an option is to limit the server to a small set. :: Discussion on Protecting SNI :: ???: In the case where SNI is useful is where you can't have shared keying material. TH: We should have a mode for encrypted SNI, and I would prefer this be the only mode (and use TLSv1.2 if you don't want it). DKG: I do think it's worth doing, and it should be the only mode. I wanted to push back against the problem that this causes problems in multiplexed environments. You just need a label for this key, and the SNI-based multiplexer just needs to manage it. MSJ: My concern is the need to cache for a very large set of servers. If you're going to handle a five-message fallback, you are going to have a lot of keys cached. EKR: Are you concerned about the server managing a lot of keys? MSJ: No, it's the client needs to manage a large number of keys. TH: The client will need to cache the keys for as long as they're valid, but it's a tradeoff. PH: If there's multiple servers behind this, it could require multiple round-trips as you fail through the keys. You might need multiple flows, in order to deal with the various failure modes. So we need to measure things carefully. CJ: In the environment where SNI is most used, it could require the owners to provide the private keys to each of the servers. EKR: So how do you want to deal with this? CJ: I think we'll need to have an option that you not protect SNI. I think you're trying to solve a problem you can't really solve. DA: You solve that by having the label contain a random address. CJ: I happen to think sharing extra info with a load balancer is bad. DKG: What you're effectively asking for is to have a unique host/port for each TLS termination point -- effectively leaking information. TH: I think it's a bummer to have that proxy architecture, but it's not the only one. You might not get a single RTT up front, but it can get you to 0 RTT later. What we are trying to optimize for is growing. MT: I think putting stuff in the label, or sharing some of this other stuff is possible. I also want to point out that enumerating the sites that are on a particular site is not that easy. There's a large space in which you can guess. MNOT: Nottingham: I think this is a very interesting issue that is balancing a number of different things, and we need to by very careful about it. Hum On protecting SNI: #1 Hum for protect SNI (slightly more than #2) #2 Hum for don't protect SNI (slightly less than #1) #3 Hum for don't know/care (very few) RH: I'm confused. On one hand you're saying you want PFS so ditch (static) RSA, but this is saying "screw PFS" and use RSA. EKR: Its a trade off. removing static RSA is not just about PFS, but for Protocol simplicity. Bryan Dixon: You're talking about having to send something to fall back? Would it make sense to send more to do both things? EKR: You are sending the reply assuming it'll work, but you're also sending the initial again. MNOT: I thought sending a anti-replay token exposed you to passive attacks EKR: Active attacks (on PFS), but not passive. We are assuming that an attacker that has access to the server within an hour, we can't protect that. MNOT: You're making me feel better about. Eric Nygren: Another thing we should pay extra attention to here is that it works for distributed servers. if it's done wrong the anti-replay is going to make things a lot worse than no retry. Also how the key for the first exchange might be less secure than the others. PH: I'm going to suggest that "close-to-perfect" is perfect, and not put in bogus data. Since it's a short-lived key, this is PFS to the degree that Mark should not be worried. :: DISCUSSION ON STATIC RSA :: Jeff Hodges: Perhaps you should define static RSA EKR: There is an RSA key that is used for the diffie-hellman ??: So this means TLSv1.2 still has RSA static but that TLSv1.3 won't? EKR: Correct. So we want to put in a condition that you can offer v1.2 if you're willing to roll back CJ: This will mean people that want to do really small implementations can't do this. Chris Newman: This is about server certs, or both client and server certs (just server). So this is to deprecate the RSAwith*. On removing Static RSA #1 Hum for removing Static RSA (large amount) #2 Hum for keep static RSA (none) :: DISCUSSION ON REMOVING COMPRESSION :: On removing compression in TLS 1.3: #1 Hum for removing compression? (large amount) #2 Hum for keeping compression? (none) :: Discussion on Stream (none) vs Block (basically CBC) vs AEAD :: Mike Jones: To clarify, would mcgrew-cbc+hmac in the list? EKR: It is not in the list, but we can add it. It does not preclude CBC algorithms, but precludes CBC stand-alone. Chris Newman: There is some hardware-based support for AEAD, but not a lot. How does this impact those hardware accelerators? EKR: I don't know what the impact is. We should ask. Hannes: The work went into public ciphers. DA: I think it might complicate us if we have to have different ciphers for different modes, especially if they have different ciphersuite id's. What would be hard is if I have to flip it. On cipher suites: #1 Hum for only AEAD? (large) #2 Hum for allowing block + stream + AEAD? (none) #3 Hum for need more info? (some) :: DISCUSSION ON REMOVING RENEGOTIATION :: JS: With authentication server type stuff, we use re-negotiation for client privacy, but we're solving that in a different way. YN: There is the case where you *may* log into a web server with a cert (or without), and we want to support re-nego for that. EKR: Do people actually do that in the browser? YN: People do. Not the cloud providers, but banks and others do use it. DKG: Cliet auth is atrocious UI, but there are cases where you need re-nego for it to work. MT: Where this starts to get interesting is if you have multiple connections folded into the same connections, but a site wants client auth. Today that's re-nego, but maybe we need to have a different way to do this, like new status codes in HTTP. Or make a new connection. DA: I dont think people in here can really answer this question about "will it break?" I provide a toolkit, so we can't rip it out if people are using it. I can try floating its removal past our team. PMcM: HTTP/2 will multiplex a bunch of URIs together, and we can't necessarily know what is where in preflight. So using a landing page means you're probably broken. Orit Levin: Maybe you put this question onto uta@ietf.org. MP: There are some that are muxing things altogether breaks the client, but maybe it's doing this muxing different security contexts is what's really breaking it. Erik Nygren: Maybe we just need a new extension for this. YN: I agree that this is a terrible thing. Having this in HTTP fixes this. EKR: Maybe we need to ask if this is only an HTTP problem, or it happens more generically. CN: In email clients, client auth is sometimes used but it's a pain. Email protocols don't use re-negotiation. You can also remove client auth. EKR: I know of one case where we need client auth. Hannes: There are people that have chosen DTLS because it has client auth. DKG: I don't know who needs re-nego for PFS refresh/cipher exhaustion PSA: XMPP server-to-server, there are cases where a TLS connection has lasted for over a year.