IETF67 Transport Layer Security (TLS) Working Group Friday 2006-11-10, 0900-1130 Chairs: Eric Rescorla and Pasi Eronen Scribes: Paul Hoffman, Tero Kivinen, Chris Newman (Jabber), Pasi (recording) Recording: ietf67ch2-fri-am About 40 people at the meeting. Eric Rescorla: Agenda and document status ========================================= 0:12:20- Agenda was announced, blue sheets were passed Eric presented document status and progress since last IETF. Pasi reminded people about IANA considerations: RFC 4681 defines TLS extensions number 6, which has also been used in several drafts. At least the SRP draft has been implemented, and you should fix your implementations ASAP since they may break when Vista ships. And in the future, follow rules about IANA allocations, and don't ship code which uses the next unallocated number. Eric Rescorla: TLS 1.2 ====================== 0:17:21- (slide 7) PRF discussion was on the list, resolved to one choice on of default PRF (for ciphersuites that don't specify anything else). -01 didn't do this right. Two variants discussed on the mailing list - Default should be SHA-256 - Use a fixed hash not tied to HMAC Eric likes the first one better Pasi says it is not unreasonable to demand SHA-256 New cipher suites can define a new PRF Three choices discussed - Default PRF is P_sha1 - Default PRF is P_sha256 - Default PRF depends on ciphersuite's integrity algorithm Those choices became: - PRF depends on ciphersuite's integrity algorithm with a minimum of SHA1 - PRF depends on ciphersuite's integrity algorithm with a minimum of SHA256 - Default PRF is SHA256 Paul Hoffman suggested that all cipher suites need to be explicit about PRF Eric decided that we should stop using the term "default" All this decision will be on the mailing list (slide 8) Combined auth encryption modes - Algorithm that provides both auth and encryption - How do we interface with these? - Can you just put a box around them? - Solution: make a hole in the document that will support them - But don't list any Russ Housley said that a draft that uses this (GCM) will be coming soon. (slide 9) verify_data - Should this be fed directly into the PRF? - Mail list discussion was mostly no. - So, which hash? - Same as above in PRF (slide 10) Target schedule - Reach consensus on the list - New version by the end of the year - Done by Prague Pasi said that in this spec, we also merged in two other documents, AES and TLS extensions. If we move to Draft Standard, we might not have two implementations of all extensions. Paul suggested pulling out the actual extensions, but leaving the extension mechanism here. He had similar experience with URI specs. Stefan Santesson asked do we even care about Draft Standard in the future. Sam Hartman pointed out that no security protocol has moved to DS, therefore we are blocking the entire IETF. Pasi added that we care about having a good spec without junk that nobody uses, even if it's not DS. Donald Eastlake volunteered to edit the extensions document. Eric Rescorla: TLS Counter Mode =============================== 0:46:13- (slide 12) Basic problem: count block management Steve Kent asked if we need an explicit IV (slide 13) Reusing an IV is a disaster Big problem is if you have parallel hardware implementations They might both spit out the same value If each hardware unit uses its ID as the high-order bytes, this fixes it (slide 14) Is this worth paying 8 bytes/packet for everything on the wire Russ said that he wrote a document for IPsec that did it like this proposal. This is only important for DTLS, how likely are we to need multiple hardware units for DTLS? Eric pointed out that GCM doesn't use the same block structure Lakshminath Dondeti asked if we could change other numbers to make it align with GCM. Eric will take it to the list. Pasi Eronen: TLS Record Layer Bugs ================================== 0:56:30- (slide 4) Fragmentation in the Client_hello handshake message. 4 OK, 6 fail Eric points out that Client_hello is special and using a different message will change the results (slide 13) He has some more tests, wants to work with other people. Looking for a Domino Server. Yngve Pettersen asked if the testing was also against clients; not yet. Russ Housley: Evidence Extensions ================================= 1:07:00- (slide 2) Motivation: TLS doesn't provide evidence that the protected content is exchanged. (slide 9) Wants this as a WG document. Eric Rescorla: Not a good plan architectually. Still requires modifying applications, so that behavior depends on client behavior. Could require journaling. Adds complexity to TLS and screws with the model. Russ pointed out that this is for cooperating peers Stefan asks if the certificate has to have the nonrepudiation bit set? Russ says no. Asks why does this have to be in TLS instead of the application? Russ says that it accomodates more applications at the lower layer. Stefan feels this is too low layer to implement this. Sam Hartman finds it really funny, since he expects Eric to say the same thing to Stefan's proposal later. We may need to loosen the requirements for purity, but we need to see specific use cases that can't be easily done in application. Russ says this one is significantly different from other proposals, since there is this evidence at the end (rather than just authorization in the beginning). Chris Newman finds the proposal compelling. Worried about the TLS architecture. Suggest it as an experiment. Russ points out this can't do that with IANA considerations. Eric suggests that we need an API for signed messages, but not necessarily in TLS but in libraries. This is creating a new construct that nobody understands Stefan points out that web-based signing is not standardized. Sam suggests you could do a record layer on top of TLS that did this (if you get finished message hashes out of TLS, and don't mind changing your application). Even the API could be the same. The only reason you don't want this is compatibility with other implementations. What might be a better approach (and might solve Stefan's problem too) is a general mechanism for adding an extra layer or second content type stream that doesn't interfere with TLS crypto. Pasi asks if there are people are willing to work. WG chairs and AD agree that this would be a charter mod. Martin Rex says that this will help application programmers. Eric asked if something roughly along Russ's proposal should be worked on in TLS WG: room supported it (but needs to be confirmed on mailing list). Eric then asked about a generic shim layer like Sam suggested: very few people showed hands, about the same for and against. Tim Polk: TLS 1.2 and NIST 800-56A ================================== 1:36:00- (slide 2) Did a full analysis now so we don't need to come back with additional comments in next IETF. (slide 10) Eric agrees that it should be fixed, even if this extension is moved to a separate spec (as was discussed earlier), but hash agility would require new extension and deprecating the old one. Tim said in this particular place, SHA-1 might not be totally unacceptable. (slide 11) Eric asked NIST to publish the information on how to blind DSA. (slide 12) Eric agreed that alerts should be more tightly specified, but needs help in going through all the cases. Pasi volunteered to help, need more from the list; NIST will also contribute something. (slide 13) Eric said HMAC truncation requires explicit agreement. Eric will study how the certificate handling works (can parties send certificates without being asked). Eric said maintaining leading zeroes would lead to interop problems since current specs says otherwise. Pasi said the secret is fed to hash function which adds the length, so it's not ambiguous. There are also other documents that would need to be changed. Paul said some implementations have gotten this wrong, and there are interop problems that occur with probability 1/256. Pasi might add test case for zero stripping to his tool. (slide 14) Tim said Bodo's proposed text clarifies things. Jeffrey Altman wants it there for stacked authentication when the higher level is authenticating. Stefan Santesson: GSS-API/TLS ============================= 2:09:17- (slide 2) Use Kerberos for client auth and key establishment When the client doesn't have a client cert but does have a Kerberos ticket RFC 2712 doesn't let the client get the service ticket during TLS (slide 9) Eric Rescorla complains that things are not in the TLS state machine, and has impact on TLS state machine. Supplemental data was meant for things that are never fed back to TLS. It seems that you need to transport GSS-API tokens around, and feed the results to TLS, could be done with PSK. Sam agreed that this is a modification to the TLS state machine, and supplemental data is the wrong message type. But I do support solving using GSS-API to authenticate TLS in a way that presents same API to applications. But this is not the only design approach. Pasi agreed that supplemental data is the wrong message, and this is modification to the TLS state machine, but something like this could be useful, so maybe the change could be done. Sam gave an example about IMAP; Sam and Eric talk more and disagree more. Chris Newman talks as an IMAP server developer. Applications can't get useful things from IPsec, so I'm nervous of putting more authentication to TLS. SASL can do channel bindings to TLS, perhaps a more modular way to do GSS-API. Martin says with GSS-API applications will see different principal names etc., so applications need some changes. Sam says that TLS could have included only anonymous Diffie-Hellman and all authentication would be done in higher layer. But TLS already supports some, but not all, authentication mechanisms. It should support more. Jeffrey Altman said RFC 2712 is broken, and it needs to be replaced with something because people need it. This proposal meets many of those needs. Eric doesn't want to add every possible authentication mechanism to TLS state machine; just add it elsewhere and use PSK. Chris said implementers get authentication wrong, so adding more types means more opportunities to get things wrong, and iterations of fixes. Authentication can be done in higher layer. Stefan says different applications have different needs for authentication, and TLS does not meet all those needs, in particular Kerberos. Sam says the combined set of protocols don't allow us to use the security infrastructure we have, and that's really bad. I want to see this fixed wherever we see this, and this draft is about that. Pasi says we need to come up with a concrete draft. Russ points out that if we do it, we need a charter extension. Jeffrey asked whether we need charter extension to deprecate RFC 2712; Sam said he might consider writing an individual draft. (2:36:30) (end of meeting)