TLS WG Thursday, November 20 2008, morning session Notes by Paul Hoffman Material from slides not copied here See for slides Document status DES-IDEA draft ready for IESG agenda PKS ciphersuite for ECDH and AES-GCM ciphers ready for IETF last call TLS extractor is in WG last call Request for input on DTLSbis What to do with newly-defined cipher suites that don't have to be in TLS 1.2 1) Say just 1.2 2) Require definitions for 1.1 to be backwards-compatible No comments from the room Poll: 1) 2 people 2) 11 people Room consensus: get definitions for 1.1 Eric Rescorla (EKR): Documents should indicate which of these two are the case Paul Hoffman (PH): We might get sloppy, so let's be careful on the 1.1 TLS Extensions Joe Salowey draft-ietf-tls-rfc4366-bis-03.txt Big outstanding extension: cert+hash Slight preference was to make the hash mandatory No objection in the room to make it mandatory Do we need crypto agility for this attribute? EKR: only useful for substitution attacks for certs with the same public key Requires a second-preimage attack; no current threat; don't need it Pasi Eronen (PE): would have to be even more powerful; don't need it Charlie Kaufman (CK): reminds us that some people say that all crypto algorithms need agility Just because it doesn't make any sense doesn't mean someone won't require agility Poll: 2 in favor, 6 against Will ask Donald Eastlake to revise draft with this DTLS 1.2 Eric Rescorla draft-ietf-tls-rfc4347-bis-01.txt Made a bunch of changes in the new draft Invalid cookies Treat an invalid cookie as a missing cookie Send a HelloVerify request as usual Wes Hardaker (WH): If you are going to retransmit, you can end up with multiple copies of Verify request Need a warning to the client about this Need to change the state machine if the last flight is lost Required to hold last şight for 2MSL Maybe alread in the spec but badly documented Added loop to the FINISHED state Out of order packets before Finished Relevant for first handshake No problem in UDP, important for SCTP Should hold them for relialbe transports Rehandshakes is a more subtle issue If you lose CSS, Finished, could get out of synch You know when you should be cutting over If you are happy with the ciphersuite, accept even if you haven't seen the Finished Probably only do this in handshakes PE: Major difference from TLS semantics Could buffer packets for a short period of time If you are doing a rehandshake to get fresh keys or resumption, this MAY is OK If you do something different in the handshake, this sounds dubious because the security properties are different EKR: OK with differentiating these two points Only do this with resumption or exact same parameters CK: What if the Finished never shows up? EKR: You can't roll back your state. Throw up an error. In TLS, the client technically needs to wait for the Finished Michael Tuexen (MT): Wants a statement that "when in an epoch, I must protest every message I recieve with that epoch" It is not clear in the spec EKR: agrees Wants more input Wants last call before San Francisco TLS Extrators Eric Rescorla draft-ietf-tls-extractor-03.txt Currently in WG last call Terminology issue with "extractor" Knew that this was a bad term, but now we cannot ignore it Doesn't like "deriver" because it is not a word Take it to the list for a hum after more suggestions TLS Fast Track discussion Stefan Santesson (no slides) Maybe resurrect the old "fast track" document from 2001 If you have had a previous session with a server, don't need to send all the material again (particularl certs) Just send a hash of what you know and go from there Quicker restart Significant optimization Old doc may need modernization (SHA-1, for example) Stefan volunteers to write this EKR: Two optimizations: Reduce latency (skip the first round trip) Reduce bandwidth (not need send server cert) Thinks this is interesting Maybe expand the scope to look at latency and bandwidth issues in general PE: Only useful when you can't do a TLS session resumption Finite lifetime Original draft had other optimizations, some were more complicated Maybe use in coordination with TLS session resumption EKR: Maybe narrow the scope to "I know your cert so don't send it" PE: Maybe cache TLS client auth as well EKR: Maybe "I think I know the following public information" extension with digest This could be done quickly; redoing fast track takes a lot of analysis Doesn't need a digest: can send even 32 CRC or UHASH Mark Brown: Maybe use certificate URL Pasi: Certificate URL is for client cert only EKR: Maybe also cache your DH group Poll of how many people would review such a draft: 6 in the room Done quite early