Transport Layer Security (TLS) Minutes Meeting: IETF-82, Thursday, November 17, 2011, 1740-1940 Location: 3F Banquet, TICC, Taipei, Taiwan Chairs: Joseph Salowey , Eric Rescorla Minutes: Jeff Hodges Version 1 ===================================================== AGENDA 1. Administrivia (5 min) Note takes, blue sheets, Note Well, Agenda 2. Document Status (20 Min) 3. TLS Origin-Bound Certificates (20 min) - Wan-Teh Chang http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts http://tools.ietf.org/html/draft-balfanz-tls-obc 4. Next Protocol Negotiation (20 min) - Wan-Teh Chang http://tools.ietf.org/html/draft-agl-tls-nextprotoneg (also http://technotes.googlecode.com/git/nextprotoneg.html) http://tools.ietf.org/html/draft-agl-tls-nextproto 5. TLS out-of-band public key validation (10 min) http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey 6. PWD Key Exchange (20 min) - Harkins http://tools.ietf.org/html/draft-harkins-tls-pwd ======================================================= Meeting Report 1. Administrivia Jeff Hodges note taker and jabber scribe ======================================================= 2. Document Status Joe: DTLS 1.2 IS IN AUTH48 waiting for author response EKR: sez he'll get back to rfc-editor in a day or two. Joe: querying about dtls heartbeat spec, and having a brief discussion on list if there's any suggestions/changes to it, believes these are things they can solve easily and results will be sent to list - queued docs - aes-ccm ciphers sean turner: on ipr statement (for ecc suites), notes that iesg wants to see that there's a proper ipr declaration trail Tero: is spec intended to run on 802.15 and run on ccm* paul hoffman: ipr statement are different for things coming thru zigbee than thru ietf, so the technology is fine, but the ipr ought to be clarified Dorothy Stanley asks: is the origin of the request wrt smart energy? Matt Campagna: answers "yes" Dorothy: notes that it has greater applicability than just 802.15 - Proposed extensions joe posted a draft "extension policy" to the list the other day so after this meeting will have to see how the policy applies to the extension drafts that are on the docket - Process for extensions joe: thinks this draft policy is pretty good, should take discussion to the list (it was pub'd very recently) (no comments at mic) ========================================================= TLS Origin-Bound Certificates TLS encrypted client certs (Wan-Teh Chang presenting) - TLS encrypted client certs - implemented for NSS and OpenSSL - the extension just indicates support for such certs - this changes the senquence of the handshake messeages - has three known issues... - incompat with DH or ECDH certs - vuln to dwongrade attacks - reorders handshake messages ie sending msgs btwn ChangeCipherSpec and Finished ekr: couple thoughts 1. easy to change state machine, but what are changes to sec properties? don't' see anything obvious but we're seeing that TLS is more brittle than we thought. have you done any sec analysis? WTC: we think this is similar to the false start extension ekr: 2. this downgrade attack is troubling wtc: make it part of Origin Bound Certificates (if you do OBC you do encrypted certs) ekr: do we only care about client authn, or only about OBC. if the latter, the prob is more serious eke: 3. have you thought about the other proposal? wtc: have read that draft, thinks this proposal is more simple sean: cipher suite explosion will come back to bite us if a separate cs is required to signal encrypted certs wtc: badra also proposes state machine change as well as the ciphersuite stuff sean (st): badra has IPR in his draft too -- need to consider that wtc: in the NPN draft, it also changes the state machine, so if other extensions need to do such we need to think about (generalizing?) this... JoeS (js): wants to get sense from room of how many folks think this is useful.... JeffH: asks for clarification of the use case for this wtc: clarifies that the "ecrypted cert" draft actually means that the client cert is conveyed to the server at a point in the handshake when the channel is encrypted rather than (just) the cert itself being encrypted. hence the change in the handshake state machine note that badra's proposal has the cert object itself encrypted paul hoffman(ph): the priacy issue is a 3d party observing the handshake and seeing the client cert go by. wtc: yes ph: perhaps this should just be wound into the OBC proposal itself, thinks the privacy gain here is questionable wtc: OBCs are used in conjunction with login cookies, which are typically protected (if one's web app is properly constructed), want the client cert to be also so protected. - Origin Bound Certificates - this proposal binds the cookies to the tls channel - see www.browserauth.net for context - Origin-bound cert is dynamically gen'd and self-signed bind cookies to this - 01 version of darft recently uploaded mostly editorial changes - implemented this extension in chrome 17 - planning to run experiments on google servers soon ph: dont understand why send this cert over prtected channel is a otherwise anon cert it seems wtc: login certs should get same protections as login cookies ph: plenty of login cookies are sent in clear doesn't believe this is sufficient reason to make changes to state machine otherwise likes the OBC proposal just doesn't want to make changes to state machine Hannes T. (ht): how often do you get new OBC ? ie how often re-gen'd? wtc: a month to year... ht: so longer than cookies...? st: i dunno... cookies can be valid for a long time ht: would be interesting to know how long cookies often persist.... ph: the cert isn't the actual identifier, and comes with a cookie, and is tied to it -- when cookie expires, do you delete OBC too? wtc: not sure st: looked in his cookie store and notes that he has ones in there with multi-year lifetimes ---------------------------------------------------- Next Protocol Negotiation (NPN) ------------------------------------------------- (Wan-Teh Chang presenting) - goal here is to save a roundtrip when layering an app prot over tls, eg http/tls or spdy/tls - status is spec just expired, but is a google tech note - is implemented in chrome, implementation upcoming in Firefox - issues raised in reviews of draft - prot strings vs port #s - prefer prot strings - eg want to be able to signal WebSockets over spdy - encrypted handshake messages between changeCipherSpec and Finished (ie handshake state machine changes) Jim Schaad (JSd): the server may get access to diff prots based on who the client is eg: google wont let me run smtp unless i have a certain account wtc; this isn't an issue for the main use case, eg negotiate diff versions of an app protocol over TLS, and save a round trip ph: NPN can be useful for not letting middle boxes know what app prot is going to get run over TLS ph: use cases 1. server doesn't want to let observer see what app prots is going to be run over a given port ie smtp, imap, pop, http, whatever 2. port #s are scarce resource, getting 2nd ports for "secure" use is discouraged, helps reuse of ports in secure fashion ekr: 1. traffic analysis makes figuring out this easy, so encryp of prot negotionation is week argument ekr: 2. transport area hasn't said they won't not alloc 2nd ports ekr: what I'm pushing against is that you're changing the handshake msg ordering in order to exchange the next prot list over protected channel Js: are folks in room here interested in this? ph: but are you asking "is wg wanting to take this on?"? Peter Saint-Andre: no, jsut if folks here in this room are finding this interesting... also, spdy might/could come to apps area, so this might be intersting from that perspective js: who thinks this is interesting? < some hands go up> js: anyone think it's awful ekr: doesn't think it is horrible, but has concerns.... -------------------------------------------------- TLS out-of-band public key validation -------------------------------------------------- (Presented by Hannes Tschofenig) draft-wouters-tls-oob-pubkey-01 - Tero and Hannes are on the author team now since ietf-81 quebec - "RawPublicKey" -- new cert type in client_hello - leverages the TLS Cert types registry that RFC 6091 defined - convey pub key in subjectPublicKeyInfo structure from X.509 cert structures (see also rfc5280) - don't need to define new ciphersuites -- but need to use appropriate ciphersuite with type of pubkey that's being exchanged dan harkins (dh): why not just send the raw pub key rather than sending a hash of it? tero: send hash to keep bytes on wire smaller js: it might be an idea to ressurect the cached-info work -- that might address the hash thing ekr: thinks raw pub key is good idea, would use it in CORE remove hash version and take this on robert moskowitz (rm): smaller is better ekr: pubkeys aren't that big rm: have risk of fragmenting on certain link layers with small MTUs, eg 6lowpan on certain media, will frag with big key ... so there is value in sending a smaller message .... not required but might be good idea st: if really constrained, use eliptic curve so keys are smaller Zach: wants to use this in CORE js: asks room about doing this without hashing the key ~20 think thats fine HT: resub doc w/o hashed pub key in it? js: yes ----------------------------------- PWD Key Exchange ------------------------------------ (Presented by Dan Harkins) - draft-harkins-tls-pwd - proposal to do certificate-less authn in TLS - no, this prot is not patented - why not SRP? EC support - use cases coming from smart-grid work devices have limited UIs - changes to tls... - various new structures are sent in exising handshake msgs in order to exchange requisite params ekr: why's this secure ? dh: tried to do some proofs in "standard model" and "random oracle model" ekr: is this published analysis? dh: trying to get some qualified analysts to look at it been told no one's going to analyze this until published -- catch 22 but is in 802.11, so sorta published st: yes, catch22 lets reach out some more dh: this is more secure than psk ciphersuites.... ekr: these prots are hard to design… there's like 50 other similar prots, why choose this one over them? yoav nir: this is pre-shared-key ? can't be salted? dh: its salted. yn: ok js: ok, what's level of interst in this particular protocol? a few people js: how many for "no" ? ekr, a few others js: don't know? a few so sorta indeterminate js: so a security review will probably help this effort go forward.... ekr: if you could get CFRG to weigh in on this, it'd be helpful dh: did bring this up on cfrg as part of eap method they looked and no one barfed, can see again what they think ADJOURNED