TLS Minutes Meeting : IETF81, THURSDAY, July 28, 2011, 1520-1720 Location: Quebec City, Canada Chairs : Eric Rescorla, Joseph Salowey Minutes : Jeff Hodges Version 1 ======================================================= 1. Agenda 1. Administrivia (5 min) Note takes, blue sheets, Note Well, Agenda 2. DTLS Heartbeat (10 Min) - Tuexen draft-ietf-tls-dtls-heartbeat-02 3. Working Group Handling for Extensions to TLS (45 min) - Chairs 4. TLS Origin-Bound Certificates (15 min) - Balfranz http://balfanz.github.com/tls-obc-spec/draft-balfanz-tls-obc-00.txt 5. TLS Extension for out-of-band public key validation (10 min) - Wouters draft-wouters-tls-oob-pubkey-00 6. DNSSEC-stapling (15 min) - Hoffman ======================================== 2. DTLS HeartBeat - Michael Tuexen Reviewed by transport directorate Chairs: will go into WG Last CAll ======================================== 3. Working Group Handling for Extensions to TLS - Eric Rescorla Paul Hoffman (PH): what's definition for trivial extension Eric Rescorla (ekr): if just using the extension field, it's trivial ekr: if there's changes that percolate outside of extension type exchange into tls processing, it's non-trivial ekr: if there's any new msgs of any kind, then it is "significant" (see slide 7) ekr: "non-trivial" if there's an isolated change, eg "side effects", it's in between trivial and significant ekr: not all that happy with this taxonomy, pls comment on it Yngve: hm, where would you place my suggested extension? ekr: non-trivial jim schaad: example non trivial would be if client says, i support DANE, server says "go look at my dane records" ekr: nominally think that's trivial ekr: modifying state machine is "significant" e.g. snapstart is significant extension PH: suggesting new names for taxonomy and trying to clarify ekr: that's nominally reasonable Policy for Trivial Extensions Sean Turner:standard practice is to go talk to tls wg if you have an idea for tls jim schaad:all these significant docs would have to go thru stds track processing ? ekr: yes PH: trying to clarify the foregoing, can AD override the out of hand dismissal by TLS chairs of some proposed extension ? Sean: yes ekr: I'd object PH: so we need advice to the AD on this PH: if WG says this sucks, chances of AD overruling are slim, but might if feels it is an important thing slide 9: Non-Trivial Extensions ekr: these are important enough [ non-trivial extensions ], then if WG only has "meh" (don't care), then is probably ok, but WG likely wont take up, AD could advance, but if there's objections, then probably should kill it Jeff Hodges: this is complex Jeff: perhaps should annoint expert to review slide 10 - Significant Extensions ekr: this sort of proposal must be a TLS WG item wes hardacker: need to be careful -- with one in past, had trouble finding five independent reviewers yngve:question on stds track-- must be stds track? ekr: not necessarily unless is "significant" ekr: anything that's a delta on a stds track doc needs to be stds track PH:wants to conflate trivial and non-trivial --- really should be trivial-- ie just have WG chairs decide--- reasonable for wg chairs to decide diff between "easy" and "OMG!" Joe Salowey: any objections to this approach? ---- ============================================== 4. TLS Origin-Bound Certificates - Dirk Balfanz Dirk Balfanz -- TLS origin-bound certificates Channel-Bound Cookies Yngwe: dirk (DB):certs cleared along with cookies with various browser mechs such as restart Martin Rex (Jabber): the Intel Pentium CPU Serial Number was a huge failure.Even on our companies PCs the Bios Option to disable this CPU feature has always been active.A single credential that uniquely identifies a devices is as much as a privacy issue as it has been when Intel put the serial into the Pentium but it could be that your targeting only a specific group of internet users, such as facebook users that do not care the slightest about privacy issues users might want to use it on several different devices (notebook, tablet, smartphone) in parallel, and once a year one of the devices gets replaced with a new one Martin Rex (Jabber): If you still need a password to attach a new device to an existing "account", but only use that password every couple of months, then users will not memorize and use different and strong passwords.Overall, the holes you have to drill for solving key management for users will kill the entire security model yngve: have another proposal, a key extraction mech, agrees on session keys.... DB: ok, we can talk about it paul wouters (PW): how would this mech interact if browser has two diff identities user doesn’t want correlated? DB: if diff vhosts on server, using SNI, so use diff certs, but they'd end up on same box David McGrew:why a tls extension? richard barnes:theres issues wiht user management to think about;separately wondering how this is better than just tls protected cookies (what we have today) ?  what's incremental benefit to this? DB: slide 5 -- "the full stack" -- there's other pieces to the fullpicture -- see that diagram DB: we can do channel bindings down the stack to OBC foundation RLBob: this does imply changes on the server and what its doing to authn.client cert authn today works differently. DB: implies server side changes -- plus implies learning how to channel bind cookies -- which protetecs against cookie theft channel bindings breaks a lot of application architectures (for stateless transports such as HTTPS) (I mean with regards to making it part of the application session id cookie) DB: status -- have interns working on this over the summer, might show up at some point in chrome dev channel. discsussing with MOZ folk ekr:the i-d just appeared, so not ooing to adopt as wg item today ekr: hum for "this is interesting"  --- ekr: hum for "think this is stoopid": ----- ekr: ok, take it to list ================================= 5. TLS Extension for out-of-band public key validation - Paul Wouters ekr: two things here, want to decouple -- one is send PK w/o cert -- other is to not send PK at all. In PGP, can ask for just PK to be sent would like to decouple these things not sure both needed PW: would like both ekr: you find pkix stuff distasteful, and on other hand, want to send less data on wire pw:well, yes, to the second, and want to get rid of contradictions (that can be conveyed will all that info in a cert) ekr: suggesting a design wehre client says "just send me your PK" and the PK goes right where otherwise the cert would be in the TLS handshake msg ekr & PW: we'll talk yngve:if you use a diff cipher suite, might be another way to package this? eg as a new anonymous cipher suite pw: it should still tell server to not send pkix stuff? ?: instead of sending cert, just send pk or hash of pk ? there's now research for say CORE where they would like to have "raw keys" in dtls they want something very bare that just transmits only what you need --- so maybe ought to leverage the two efforts .... pw: looked at using the dnssec RRs eg dnskey, but there's some issues.... ekr: ought to phrase this as a new cert type eg a cert that's just a public key client has no way to assert their desire except via extensions or ciphersuites -- server could express in cert type field what it is it is shipping back EKR (on Jabber): So, what I was trying to say was: ClientHello + "Send me a public key"; ServerHEllo + "It's coming"; Certificate w/ the public key jim Schaad:what additional priv/sec issues do you see from this, since you're taking out the cert validation step, e.g. one way to leverage this is via DANE -- so where do that outofband check -- before the Finished message is sent ? Jim Schaad: whats implecations to the name matching draft ? PW: there's some sec cons in the spec, but need to think of more Richard Barnes:so this I-D ought to specify more about what the properties of the outofband validation mech ought to be pw: yes Martin Rex (on Jabber) it is a completely different scheme to establish trust to keys -- you do not need certificate path validation Joe:what do folks think?is carrying bare key info is a good idea: -- Joe: a bad idea?  -- Joe: ok, that was fairly strong in favor, but we'll have to figure out on list why Bob Morgan (RLBob): wont some work along these lines need to be done for DANE to actually work with tls ? PH: not needed. ekr: so on list say why you do or don't like this ======================================= 6. DNSSEC serialization - Paul Hoffman  this is a briefing, no action items http://www.ietf.org/proceedings/81/slides/tls-2.pdf PH: Important note: I am not Adam Langley, nor Dan Kaminsky -- but Adam has reviewed the slides ekr:wondering about how this works with DANE -- trying to understand the value proposition PH:we're talking DANE now, but this could be valuable to other stuff down road richard barnes:some info in dns that's apropos to the tls negotiation -- and this serialization into the cert allows the work to be offloaded to the tls server ekr:that's what i was saying, need to do sec analysis, don't think sec properties of active secure dns lookups are equivalent to having secure dns chains embedded in cert PH: AGL's I-D specifies only how to construct the serialization of secure DNS serialization -- NOT how it might be used or its relation to things like DANE paul wouters (PW): this is not tls only thing, where "this" is serialization of secure dns data and for the how to use in tls, pls make it not pkix-dependent yngve:wrt slide 5, there can only be one defined ocspStatusRequest, so my draft is about expanding that, need to fix that before this option will work Martin Rex (on Jabber Proxied by EKR): I may take some talking to convince DNSSEC library implementors to provide functions to verify DNSSEC records provided through a (standardized) flat memory buffer, rather than having it collect those records itself PH: yes, that may be way to do it richard barnes:might as well do this as a tls extension rather than as a cert extension Phillip Hallem-Baker(PHB):likes OCSP means, put secure dns data into ocsp data that's stapled in the tls channel so matches the ocsp semantics so if even decided not to do any of this, secure dns data pickling (serialization) will be needed in various places wes hardaker: wouldn't worry about lib issues, there'll be various libs that will do this sort of serialization way before this spec progresses PH: will such lib methods be useful to apps that need this info ? wes: yes.this sort of thing is a magic bullet that will help secure dns uptake wes: we need to be able to insert records thru memory rather than pull over network ekr:from UA perspective:ua does resolution, domain needs to be signed, ua verifies that (?) or not, get A recd and maybe TLSA record, then fire up TLS, get blob back, check stuff in blob with the A record and the TLSA record ekr: i don't think i as client can distinguish the case where i'm bhind non-secure dns resolvers, and the server is offering this extension, or if the server isn't offering it ....  what attacker does is that he messes up dns resoluion so you can't get any dane info or dns, and so you go to the server and he says "i don't have this extension" and you talk to him any way and he's a trojan, ur pwn'd PH:postulates having secure dns "lock" ekr: you could also do CALock ekr & rich barnes:some discussion of what it means to get or not get secure negative statements from dns yngve & PH: PHB: the thing i want is really to know whether "this site speaks tls or not"-- need to know that first in most cases --- end