Proceedings for TLS WG * DTLS 1.2 Issues (EKR) + Document is in WGLC + final handshake message loss issue: + final server 'finished' is sent but not received by the client + behavior under loss + receiver + is fairly easy to figure out (retransmits of last expected + sender + sender must save the last flight for 2MSL + epoch wrapping + what happens when the epoch wraps? + solution: don't let the epoch wrap (MUST do a complete rehandshake first) + What about state loss + state loss from a client reset is a problem + Solution: + when new epoch=0 arrives, assume a potential problem + must keep the only state too though to make sure it wasn't a DOS + Wes Hardaker: this is a problem with TLS/TCP as well since TCP can be equally as confused. The only difference is that DTLS doesn't have a heartbeat to check the up-status, but many TCP implementations are just as bad and don't notice a drop. + misc mostly editorial corrections + 2MSL + concern was that it was referencing the TCP MSL from kernel code + not true: you should pull it from the current TCP spec; will fix document + record sequence numbers for retransmitted hello + What happens if a hello message is lost? + client retransmits + What should the sequence numbers be? + proposed solution from Michael Tuexen to reflect client SN Conclusion: No objections + CCS position is hard to determine + State machine still needs to be looked at in order to determine the right solution + proposal is to leave it as is, but add a helpful note about doing this. + Paul Hoffman: Please post the 2MSL solution to the list so that people actually hear it. I'm not sure everyone has seen it and more time is needed. + : you spoke about client state loss, what happnes if the server loses the state? Some protocols have purely unidirectional approaches where only the clients send messages + EKR: good question: there isn't a whole lot we can do about it. You've lost crypto state so there is nothing to do about, so you can't prove. + Can this be included in the heartbeat draft? + multiple people note: heartbeat has expired? + same missed name: enforce renegotation + EKR: you should only do 65k renegotations at max. Suggestion was, don't get to 65k. Pretend you lost your state and reset. * Charter + TLS charter is too old + new goals: + primary: TLS protocol, extension, DTLS avoid major changes + secondary: recommendations for yuse + stephan: can we include the cached info stuff + Joe: there hasn't been a lot of discussion on it. is there anyone interested on continuing to work on it? + discussion with conclusion and discuss on the list. + Simon J: is there interest in moving the openpgp stuff on the standards track? + ask on list; no discussion * TLS Next Protocol Negotiation (Mike Belshe; Google) + wants to use something other than HTTP beyond TLS (SPDY + didn't want another round trip, and this extension helps + different port number is problematic because only certain ports are open now (80 and 443). + could have also used racing connections (try 443 and something else) + upgrading at the HTTP layer is problematic outside of TLS (and burns an extra round trip) + new extension is in use in Chrome today. client advertises, server can do, and client sends a nextprotocol handshake. + why not in the clear? don't want new discrimination against the new protocol, so leave encrypted. + patches are available for NSS and openssl + default is to assume server doesn't support it and it uses https + Sean: have you discussed this anywhere else? + have been public about it, so it has been discussed in speedy list and other things + EKR: was discussed in HyBi but conclusion was it had to come here + Paul H: is this meant to be coming into the WG? + Mike: want to drive it to the next step. Hasn't been submitted formally (draft is currently expired). + EKR: lets talk afterward + Paul: I really want this to move forward. This might make a lot of people really happy. Please be public about how you're moving to the next thing. * AES-CCM ciphers (Matt Campagna; Certicom) + motivation is 802.15.4 and want to run CCM over that + specifies 4 new ciphers + other draft specifies other modes: multiple combinations of modes. + proposal: accept these two drafts and WG items. Interop is already done somewhat. + EKR as himself: not excited about the the proliferation, but realizes we're stuck and thus we should take these drafts on. second, what's the advantage of the longer vs the shorter MAC. + answer: The short is expected to be used immediately + EKR: there is also a mac truncation extension. Have you thought at all about trying to use that instead? + I don't know if that's been considered. + EKR: At what stage are you at? + Doesn't know, maybe I could ask someone that was at interop + Robert C: we've been using multiple things for interop + Matt: is there an aes counter mode already defined? + Paul Hoffman: + I'd like to see this as a WG item without the long-mac unless there is a reason for it. + Joe: Chairs will have a discussion and talk about whether it should be a WG item or not (implied: being code point updates, it may not need it). * EAP and TLS (Yoav Nir; Checkpoint) + authenticates client similar to IKEv2 + TLS/SRP requires password to be on the verifier + where is this useful? + http auth + ssl clients + describes new message changes + question is, should this be adopted by the WG? If not, we'd advance it via individuals? + isn't this like federations? + no we're not interested in federations. This is an alternatives to web forms + EKR; this is a violation to the TLS state machine. This has multiple problems because of that. TLS was not designed for this. It can't go over standards track as an individual. + Simon: as an implementor, modifying the TLS state machine is not a problem. + Simon: there are other mechansims that want to do channel binding to TLS; have you considered using some of those other message examples (like or not like finish). + Yes, they've thought about it. Moving it into the infrastructure makes the implementation more robust by forcing a better channel binding than a web form + discussion is done before the finish is sent; thus the implementation may not have proper access to the channel binding anyway. + Dan H: what credentials are you going to use in EAP? + either passwords or RSA tokens + Dan: would PANA not satisfy? + I don't remember why PANA isn't appropriate. I'd like to second EKR; this isn't a good idea. + ?: PANA isn't a optional idea for you because it isn't widely implemented, but GSAPI is. Consider that + ?: Observation about UI: There is a reason that HTTP webauth isn't used: the web admin can't have control over it and make it "theirs". + Sean: this may be out of the scope of the WG: you may need to change the charter to do it. You must change the charter. + Martin from jabber: also doesn't like it, and other discussions in 2007 need to be reviewed. * Renegotiation (Yngve Petterson) + probing results about renegotiation + Many still support SSLv2 + 7.9% support servername indication + how many have read the draft on multiple CSP? + a few + Conclusion: no action needed at this time Thanks to Wes Hardaker for note taking.