TLS Session 1 - IETF 102 * Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-tls-05 * Document status update * TLS 1.3 deployment (Rich Salz) * [SLIDES: https://datatracker.ietf.org/meeting/102/materials/slides-102-tls-ietf-102-tls-wg-chair-slides-10] * Turned on public beta of TLS 1.3 at Akamai in April * Very few people enabled it; shows week/weekend variation * Saw no complaints! * Nick Sullivan (CF): similar numbers (draft 28) * Q: what percentage of total traffic? under 20% * EKR for Moz: 1% sample of clients... very little 1.1, 1.0... 3% 1.3 (don't believe these numbers within a factor of 2) * Deprecation of <1.2 * Requesting some feedback as to systems that might be affected: * Meaningful statistics across different applications using TLS * Examples of systems or applications for which no upgrade path is available * Considerations for networks where upgrades may be difficult * Deprecated protocols in limited use cases? For example, HTTP to internal or partner networks that is explicitly allowed by subdomain or some other means of identifying applications, systems, or network domains. * MT, others: may not need to consider usage stats in considering this document * e.g., by publishing this document, nothing breaks immediately * Lots of thanks for publishing it. * DKG: we can afford to pubish this without driving numbers down to zero. * multiple audiences for documents like this, can make sure this is useful for many audiences. * clear advice for implementers: can't remove entirely, but here are things you can do. * We publish this now to drive adoption, not wait for adoption to drive * Erik nigren: we want to make sure people don't even think about 1.1 1.0 when they are implementing. * Nalini: need to have guidance for implementers... people are trying, it's not easy * Jeff Hodges: support the draft, but the WG could do a better job of facilitating deployers * Exported Authenticators (Nick Sullivan) * [SLIDES: https://datatracker.ietf.org/meeting/102/materials/slides-102-tls-exported-authenticators-00] * "Enable a peer in an established TLS connection assert ownership of the private key of an additional certificate. Proof can be sent out of band." * motivated by HTTPbis Additional Certs draft * formal proof of security at last IETF * New last call * Jonathan H-something: would be nice that authenticators would be unique, makes the analysis easier * Mike Bishop: already have a req that the context be unique within a connection * Jonathan Lennox: there's a "not" missing in the results of last call slide. Nick: yup. * TLS-DNSSEC-CHAIN (Paul Wouters): * [SLIDES: https://datatracker.ietf.org/meeting/102/materials/slides-102-tls-a-dane-record-and-dnssec-authentication-chain-extension-for-tls-00] * "Resolving the downgrade attack without narrowing the scope" * Anti-downgrade options: * Do nothing * Fix everything in new TLS extension * Two zero bytes in this RFC, specify non-zero semantics in a separate update RFC * Two byte TLS extension pin TTL (in hours) * Variable-length (0..255) reserved field (default empty) in this RFC, syntax and semantics in separate update RFC * Nested extension block (just like new TLS extension, but even more complicated) * Richard Barnes: current document works fine with assertive forms of DANE. A: confirms you're not under attack. * No, even in that scenario you may be under attack. The point is to auth even in the presence of an attacker. * Ben Kaduk: attack as in "someone trying to muck around in the network" or "someone got a stripped cert" (JLH: may have gotten that wrong) * A: authentication of the DANE part [something-something-something] * Erik R.: * "don't think there's consensus": fair amount of concern about pinning * Concern: Similar to HPKP * Preference order: (i) Publish draft as it is; (ii) publish draft with extension blocks; (iii) ... * Paul (response): this concern has been highlighted before, but no solutions * DKG: draft has value as it is. * are clients that don't do WebPKI that can use this. * looks like HPKP because we're not convinced that the operator can make these decisions, especially in delegated operations (hire someone to do something) * fan of HPKP, sad it went away * can we get this draft out the door and then deal with downgrade? * A: afraid it won't be updated to add this later * A: danger is that we're here in four months with a bis draft and have the same problems * Ben Kaduk: with AD hat on * key point is that we can't rely on PKIX trust anchor to tell you anything about [extension/DNS] (?) trust * pinning is partial mediation * question: how do we move forward? (options: publish as it is OR get a new document OR "leave a hole that we fill later") * take off AD hat: shares DKG's concerns. experiences we have with HST, HPKP it's presumptuous to say that we know we can fill this hole now. We don't know how to solve this problem. * Viktor: * "there is no assertive use case" * if you're a server in webpki world, you're not going to get clients if you go with DANE * only application that works for the draft are those which mandate the extension * Managed to get some consensus around denial of existence * Value goes away if the thing is trivially strippable. * Lots of folks are very excited about MTA-STS (UTA-WG)... pins a mechanism, not the data * No data gets pinned, simpler than STS/HPKP... this is STS de minimus (minimal STS) * DKG: concern is not about what is being pinned but who is doing the pinning... TLS endpoint itself is doing the pinning... in MT-STS the operator doing the pinning is the controller of the DNS Zone. * Nico: * this is a bit TOFU-ish * no silver bullet for the problem * We're not trying to say everything should be on webpki, or everything should be on DANE * About pinning: only about pinning the extension, different from other pinnings * someone has to do the pinning on the client side * as long as you have the extension, it works * problem: when you want to go back to an earlier version (but not a big deal) * most implementations will be getting data asynchronously in the background * about the two bytes: speculative in one sense but not in another... unless we are opposed to pinning in any circumstance * if you are not opposed to pinning, give us these two bytes * Wes Hardiker (ISI): * Ext pinning is really different than data pinning. * When we rush documents out the door, we end up with the potential to have a mess in the future * the worst thing you can do is to create two conflicting extensions * in terms of opt for least operational complexity in the future, it seems to me ... * essentially we'll have two version interactions and a diediedie in the future. * Preference is to kill this now, but we can leave it in as a blind field * Sam Weiler * Could we fix this in the DNS... can we steal bits in the DNS to signal pinning in the DNS * A: no, may have a service provider that may strip some DNS records. to avoid that you're getting DNS through this extension * EKR: * two questions: 1) is if pinning is good for this; 2) if so, how should we proceed. * Pinning is brittle in deployment... still have a problem with deployment. * It might be so that pinning is good. * So, if so, do we hold this draft until we solve this problem... or we can have a placeholder. * You want a very small placeholder, [will be hard to rev if we are making a mistake] * we work on protocols that we can "grease" (get deployment of), not ones that [we aren't sure about] * Chris (CMU): * to EKRs point, not clear if you zero out the bytes that you have to solve it. * working group can solve this problem later and potentially not use those bytes in the end. * not the end of the world. * Richard Barnes (Cisco) * clarify incremental deployment issue (Viktor raised) * switching b/w modules of authentication * A: if there is no pinning, you cannot chose your PKI system... one that's allowed and [one that you think is allowed but actually not?] * extension advertised in ClientHello... (JLH: they are arguing over each other at this point) * trying to authenticate but not bind yourself to [something] * Real Point RLB want so make: * we screwed up DANE, we have mixed up two very different use cases (assertive v. restrictive) * A: RLB is wants to remove the "DANE use case" * There is not "a" DANE use case... there are many. * Added language to the draft to only talk about assertive use cases. * [JLH: Shit has devolved at this point.] * Chris: we may decide to just put this back in the editor's queue and address later. * Shall we hum?s * Sean, how many people read the draft: 20-30 * Lucy Lynch (point of order): chairs can convene a design discussion * Sean: we tried to do that... devolved. * We are at a deadlock * Ben K: not comfortable publishing the doc in the RFC Editor queue. * Whether we add additional text to it, describe uses cases for which it's a good solution. * Leif: it's a major change, another WGLC is necessary. * EKR: can't publish it as it is, but we have some strong opinions... an no consensus to publish. * RLB: we had a hum at last IETF about this and strong consensus to do nothing. * none of that resulted in stronger, more compelling arguments. * don't see additional support. * Paul W: given a number of issues to the authors at last IETF and the authors did not include that material in the presentation. * Don't think that was fair, that's why I asked to present here. * Paul Hoffman: the large discussion on the mailing list may have changed minds. * old hum, and mailing list discussion may have changed consensus. * We're going to postpone this discussion to Thursday. * Will probably pull from the Editor's queue but will revisit. * EKR Connection ID: * [SLIDES: https://datatracker.ietf.org/meeting/102/materials/slides-102-tls-dtls13-and-connection-id-00] * IETF 101 had a long discussion about marking CID explicit/implicit * mark that it is there, not mark the length * agreed DTLS 1.3 might not be as mature given QUIC work * both use CID extension. * DTLS 1.2: big question: how to encode that CID is present... bit in length field or shadow content type values * content type hack... started to make people sad, including MT * MT suggested suck in the DTLS 1.3 framing... allocation one extra code point * MT: we have seven code points left, you are taking four of them! * if we do this, we chew on one code point and have six left (JLH: think that's right) * alt alt design: do a hack where the true Content Type is outside the encrypted envelope * rationale: we're trying to make 1.2 better but it already sucks, so we're not making it much worse. * Thomas: has a third opinion/design: go back to orig problem. 1.3 headers now implicitly allocate a fifth code point (?). * if we pin one of these bits, instead of 011 but 0110 (?)... we get back 16 code points. * problem is that we're running up against packet length field * MT: we only have ten bits in that space... probably good for many use cases. * We have 14 bits... you want to take a flight bit? * Don't care about 1.2, willing to burn a byte for 1.2 to have connection ID. * Hannes: we can't use the 1.3 header, problem is 1.2 * Thomas: [?] * Hannes: this is acceptable, especially as it will encourage movement to 1.3 * DKG: it should be encrypted. * DTLS 1.3: * putting extra flight bits in there, not my ordinary preference. * Question: Should we increase the bits? * If we're going to have one size, it better be big for anything * (Martin and EKR decide to take it offline) * has new connection ID message * if we increase sequence number, new CIDs are pointless * idea is to always have Connection ID * same function as QUIC: use some of the ciphertext as input to PRF * MT: * are we planning to cipher the epoch? * EKR ANSWER: No. * MT: QUIC discussions about Connection ID * we should not make serious moves until it settles down there (EKR agrees, but thinks DTLS 1.3 is moving faster on this than QUIC) * EKR: there's no reason they shouldn't have the same design * QUIC should resolve the design issue soon (maybe in IETF102 itself?) * DELEGATED CREDENTIALS * [SLIDES: https://datatracker.ietf.org/meeting/102/materials/slides-102-tls-delegated-credentials-00] * not a lot of work done at the last IETF * motivation: reduce exposure of certificate private key to memory disclosure vulnerabilities * history of comprimises in lots of web servers (heartbleed most famous of it) * TLS extension sent from client to server * server will send back "delegated credentials" * point is it is short-lived * short-lived key is used to finish TLS connection * client validates these delegated creds * simple structure * implementation status * several ppl have worked on implementation * there's a version in Go * achieved interoperability * Cloudflare has a plan for DCs (fall this year) * Object ID proposal is blank in the draft at the moment * QUESTION 1: whether we should move to Object ID for IETF security OR use ExtendedKeyUsage * David Benjamin: * EKU usage cases * Proposal 2: * separate use of private key, to be not used in TLS * should only be used for DC * problem is for client software: dynamically choosing certs * Proposal 3: (by Christopher Patton) * in case of RSA, whole list of cipher suites * proposal: pick up one ahead of time (you can only use one then) * makes analysis simpler * manufacture more than one DC * lot more explicit control over how DC is used * Subodh: * also discuss DC signing algorithm in the structure * when certification validation fails * Ans.: not in the current pull request, having it explicitly in the DC will make debugging easier * Proposal 4: * draft supports TLS 1.2, 1.3 * proposal: drop support for TLS 1.2 * natural assume to new stacks will support 1.3 * MT: * what is the cost of dropping 1.2? * A. dropping 1.2 will reduce draft complexity, so it's preferred * We don't have a formal verification of the proposal design; will be nice to have: any volunteers? * [Daniel] * is this not useful if there is no universal adoption? * A. use a remote key, hold your key in another location * EXPORTED AUTHENTICATORS (someone from Royal Holloway) * [SLIDES: https://datatracker.ietf.org/meeting/102/materials/slides-102-tls-layered-exported-authenticators-00] * Ben Kaduk: * Do you have a formal definition of jointly authenticated? * A. Not in the drafts currently (GG: slides have a definition) * proposing an extension to link EA to previous ones (chaining) * not the same thing as joint authentication * if a server sends this, it means it accepts client certs * doesn't say anything about future certs * USE CASE 1: update pinned certs (prove control; provide authentication even if you're middleboxed) * USE CASE 2: prove that you had control in the past * Mike Bishop: does that imply every request is ordered? * A. chain can diverge, you can have a forest. only joins in your branch * A. if I have two branches, they can have two different authentication properties (wouldn't suggest this, but it ensures it doesn't break) * http layer, we do multiple requests, there is no order: need to think about implications * A. wouldn't expect a difference; as long as the server knows the order of replies * EKR: * unusual design of the proposal, typically we don't ask people attest to "random stuff we send across the wire" * A. the request would usually contain a request context and some extensions * how am I supposed to know which one should I link to? * A. I mention number * What makes me check it? * A. Draft says you have to check. If you include it in the response, that means you checked. * Nothing enforcing it. Idea: only send the prefix of the hash in the request * A. Yeah, then it needs to prove that it knows the hash * Chairs: * too early for WG adoption for this draft * A. just wanted more attention for it TLS Session 2 - IETF 102 * Administrivia * Re-use of PSK across 1.2 to 1.3 * Hannes: it doesn't sound right * having a negotiation here sounds like you can't reuse a cert you used for 1.2 in 1.3 * EKR: the crypto analyses of 1.3 assume that any PSK is used with a single KDF * do we know of actual problems here, no... but that's the basis of the analysis * David B: to add to that, the reason the certs are ok to be reused is that the context string has 64 spaces to clear the client random * Hannes: IMO a good approach would be to have the formal methods guys analyze that before we suggest that and confuse people * Joe S: take it to the list! * Cert-based auth with external PSK (10min) * Current 1.3 key schedule uses a sig across (?) * DH is the thing that drives the key schedule * Subsequent handshake based on resumption PSK or that and an additional DH result * proposal: add an additional option to the initial hs to include an external PSK and combine with the DH * want to do this for quantum protection, you've mixed in this external OOB-distro'd PSK so that any attacker has to get the PSK too * (ladder diagram of where this would fit) * syntax: boolean, present or not. If you negotiate, you'll agree to do that. * presently language in the spec that precludes PSK when certs are used. wouldn't be used with a resumption, just external * group of TLS peers would need to get the PSKs. if the quantum computer comes, have to compromise one of the numbers of the group to comp PSK * ask: WG adopt as a work item, then review and comment * EKR: the way you're phrasing the semantic are odd... PSKs can be mixed with DH already. * seems like you're saying, instead of bypassing... want an extended signature even (?) * Russ: if a PSK is present, the auth is based on that * I want to base authentication on PSK and the cert * EKR: protocol is: I insist that as well as using this PSK I want to use certverify (?) * recall, we removed this for a few reasons: complexity reasons and known attacks against one variant of TLS key schedule. * would want to see a formal analysis before we get very far. * MT: think you may have excluded the one case I care about. Wouldn't allow this with resumption PSKs. * to EKRs point, when you are post-hs and have PSK, you decide to continue with it. * Russ: was trying to make the smallest change... MT: you made one bigger than necessary * MT: in addition to this PSK, I also expect you to auth the cert * Nick: would second MT's point: would be useful to have this for resumption as well as static * Valery smyslov: repeat comment from LAMPS, uses a similar technique * Russ: Not sure I can align with your terminology. * David McGrew: speak to the goal: this would greatly expand PQ cipher suites, supportive * Chris: who's read the draft? (lots of them) continue on list and we can do a call for adopt * TLS PAKE * TLS PAKE * difference is a rev of the draft, fixed typos * bind to SPAKE2 originally now we just have any given PAKE protocol * pretty general now * Other PAKEs ... dragonfly, OPAQUE * ID protection? do we need to negotiate PAKEs? * Chris: who is interested in this? (about 10 hands) * EKR: who would implement this? * RLB: OpenSSL? * Sounds like an argument against adoption * Chris: take it to the list! * EKR: I'm pushing back bc the history in PAKEs is that a lot of effort has been expended to specify but very little use * Rsalz: you'd want to see it used in applications or we wouldn't want it in. Just turned down JPAKE. * RLB: have had product requests for something in this general form * Ticket Requests * servers send you a fixed number of tickets per connection (boring gives you two, for example) * some clients want more, but we don't want them to go to waste * would be nice to specify how many you need * proposal: post-hs message can request tickets on demand * alt design: in a new extension expressing how many you may need upfront... essentially a request and server can do what it wants * does not allow for dynamic vending of tickets * if clients will never ask for more than four, lets just do that. * would be nice if we can avoid cases where you vend out tickets to other processes * Nick S: this should be more like an exporter * David B: can grow an unbounded number of ticket requests... H2 fixes this by bounding number of streams * obvious answer is you should not have more than 7 requests open at a time but that sounds arbitrary. * Rich: the other alternative is to deploy (?) * Tommy: we don't want a solution that relies on H2 or a higher layer, want a solution that is in TLS * problem that can happen with building up requests is pretty bad * best guessing is just fine * Kyle N: if we can get the exact number of tickets we want in the initial requests that would be nice * Kazuho: we use this to get tickets for different protocols, what's up then? * David B: even if you need 20 tickets, it's not obviously wrong to send just even 1 * if you make 20 connections but they're all in serial, one ticket is just fine. * once you reach your max parallelism, you'll have a steady state of tickets * we should just be sending one ticket * Chris: potentially? * Joe: how many people have read? (~20-30) * how many think this is something people should work on? (a few weak hands) * more discussion on the list! * ESNI (30min) * There will be controversy * We didn't do too bad in 1.3 * Client ext (SNI, ALPN) are sent in the clear, and you might want to hide * Why? Surveillance, censorship * sources of server id leaks * DNS resolution (DPRIVE/DOH), SNI (this draft), server cert (enc now), server IP (CDNs/multi-tenants), traffic analysis (yuck!) * we have spent a lot of time on this... almost the entire 1.3 time has had some proposals. * very hard! what's changed? * 80/20 solution * worried previously about these things "sticking out" * needed a solution that works for CDNs and hosting providers * this puts everyone behind the same anon set * (diagram of network arch for this... split vs. shared mode) * DNS pieces, TXT record under _esni.example.com * Then send a new extension, EncryptedSNI * Key derivation: client keyshare has to match the group from DNS, clientshare from ClientHello * potential for downgrade attacks * interactions with middleboxes, a middlebox that doesn't understand an ext should not send them along, create a hard failure * how do enterprises disable ESNI? either don't want to use it or turn it off under heavy loads. * strip ESNIKeys records? keep TTLs short? client policy push? * why not just encrypt everything? * ESNI permits key separation, interacts poorly with split arch * middleboxes will strip every ext * could later introduce something that encrypts "the rest of the extensions" (e.g., ALPN) * This draft is all wrong! * many errors that we need to fix. * base64? non-text RR type? alt-svc instead of _esni record * TLS maybe don't reuse key share? but have to bind the client KeyShare to ESNI * However, we feel like the draft is in the right direction * Update on interop * Got this into NSS! client of BoringSSL and picoTLS * Browsers firefox, safari * WG interest? Next steps? * Ben Schwartz: support adoption * want to put a replacement SNI field in the existing SNI structure, so you can get the behavior of client SNI * Darius K: like this, this is a problem we should solve. * WG should consider encrypting other things in ClientHello with this mechanism * Mike B: support it, moving in right direction * fails to cover multi-CDN cases. in many cases there are multiple CDNs they are shared... need to disambiguate. * Brian T: this is a sick hack, like it, we should do it here * caution about DNS experts waxing about TXT or whatever records? * DKG: excellent work. Thank you. * to address Bishops, bind to internet.arpa instead of a name. * advantage is the key looking for is the key for the endpoint IP address * Q: does Apple know that you are doing a presentation with Comic Sans? * Tommy: stop using comic sans * good work * speak in favor of the current structure for DNS... want to keep certain properties that exist now. * seems deployable this way, it will get through * one though regarding IP address solution: very cute. concerned about the latency here. May be able to do TXT query before A/AAAA * ?: know acknowledgment that the ESNI was accepted by the server or ignored. * PHB: like the work, split the draft into two. crypto and TLS piece in one... all the pieces about getting parameters out of DNS in another. * very hard to get certain records through in DNS, hasn't changed in 15 years * Call for WG adoption * hum for adopt. * Yes: mucho hums * No: no hums * We will adopt this doc.