# TLS at IETF 114 {#tls-at-ietf-114} ## Administrivia (5 minutes) {#administrivia-5-minutes} * Blue sheets; log into the "local" meetecho tool * Minute-taker: Rich Salz with help from Nick Doty * Jabber Scribe * NOTE WELL * Agenda revision; "TLS flags" document moved to end * Doc updates; see chair slides ## Working Group Drafts (85 minutes) {#working-group-drafts-85-minutes} ### cTLS (Ben Schwartz) {#ctls-ben-schwartz} * Recently joined as co-author * Major changes: * Profile ID's are registratable bytestrings if under four bytes (IANA); if more than four bytes, only significant within a significant deployment * No longer a "compression" layer; was layer betwween TLS and its transport. Consensus is that this was not very simpler, prefer to have cTLS authenticated its own transcripts (without TLS). That's ambiguous so you prepend template identifier as a synthetic message. Template was JSON, is now a binary format roundtrippable to/from JSON. * New handshaking framing option since most handshake are expecte to be small; `handshake_framing=false` * Open/interesting questions: compressed EC points, compressed certs, versioning, etc. * Expect some analysis, but also expect that this will map exactly to the TLS 1.3 guarantees. ### A well-known URI for publishing ECHConfigList values (Stephen Farrell) {#a-well-known-uri-for-publishing-echconfiglist-values-stephen-farrell} * New co-authors (Rich Salz, Ben Schwartz) to cover some use-cases * Sample code (this is a work in progress) available; see slides. * Breeze through technical details * Should we make this more generic (everything a web server would want, like ALPN etc). Prefer to be ECH-specific. * Add ALPN? Yes probably. * Think about what other, if any, inner CH content to add. * think about what parts of SVCB to support. * Other open questions/issue that were raised. * EKR: conflicting lifetimes? * Ben/Stephen: not the intent to replace generic HTTPS RR, only origin/DNS-server information to add RR data. * Ted Hardie: If there are other use-cases, think about caching infrastructure. Maybe register a provisional, write an experimental RFC, see if it's worth doing. * Ben Kaduk: if you want to limit to origin/dns, then don't register a url. * Stephen: it's a reasonable argument. ### IANA Registry Updates for TLS and DTLS (Sean) {#iana-registry-updates-for-tls-and-dtls-sean} * SAAG suggested adding "D" for deprecated/disrecommended. * Tough because new registrations have happened since TLS 1.3 RFC. * Short-sighted to not include Recommended column in HashAlgorithm, SignatureAlgorithm, ClientCertificateType * Table of changes; see slides. * Martin: if there's no RFC that says "this is bad" then it should be "N" * Discussion of some of the N or D ratings * Revision planned, seeking reviews, hopefully then WGLC ### Deprecating Obsolete Key Exchange Methods in TLS (Nimrov Aviram) {#deprecating-obsolete-key-exchange-methods-in-tls-nimrov-aviram} * TL;DR: Remove RSA keyx, static FFDH, FFDHE only when >2048 and a safe well-known group, no static FFDHE * Open issues: what are safe FFDHE groups? What shoud client do if it can't/won't verify group structure? * Ben Kaduk: create a registry for "safe" named groups? Would that work? * DKG: we should address why the pen-testing tools are wrong to complain in some cases. * Nimrod: Will summarize the points made and bring it to the list. ## Individual Drafts and Presentations (30 minutes) {#individual-drafts-and-presentations-30-minutes} ### TLS Extension: Validation Request (Rob Segers and Ashley Kopman) {#tls-extension-validation-request-rob-segers-and-ashley-kopman} * Global aviation uses SCVP (RFC 5055). * Interop is key, states are sovereign, need standards. Moving to IP (as opposed to OSI). * 5\.5K entitites, 25K aircraft; trust anchor distribution issues. * Block diagram; see slides for details. * Extension to ClientHello message, TLS server does SCVP query, extension to CertMessage that includes the scvp response. * Uri Blumenthal: appropriate for constrained devices; Hannes: yup, works fine. * Response to question from EKR: plan is to get Boeing, Airbus, etc., national aviation authorities; seem to have good representation. Server-side needs changes, but that global count of them is manageable. ### Using Attestation in TLS and DTLS (Hannes Tschofenig) {#using-attestation-in-tls-and-dtls-hannes-tschofenig} * See also HotRFC presentation * Doing prototyping/experiments. * Works with RATS models; supports client- and server-side, usable with different attestation formats, TEE agnostic * Need a nonce, so just using the "obvious" certificate\_type is harder. * Intent is to use for both client- and server-side attestations. * Monty Wiseman: Need to be able to specify what kinds of things you want to attest. This is a lot of work, happy to be involved. * Nick Doty: why is this a TLS protocol, not an application protocol? * Hannes: good question. Want some guidance. * Nick: serious privacy risks that should be addressed earlier rather than later. * Henk Birkholz: meaning of evidence is unclear. Yes I know this is a 00 draft. Don't use attestation term. Hannes: yes, I will use the "Henk brush" for next version. ### NIST PQC Announcement (Sofí Celi and Thom Wiggers) {#nist-pqc-announcement-sofí-celi-and-thom-wiggers} * See also CFRG notes. * Parked draft ietf-tls-hybrid-design is the way to go * Certificate-based authentication * Post-quantum signatures: tradeoffs * Some are relatively small/quick, but "if implemented correctly" caveat and may be hard to implement correctly. * Hash-based would be slow but conservative * NIST is calling for new signature schemes, but UOV has very large public keys (>400k) and will take several years * Prior experiments on the Web * mostly on key exchange, need more authentication experiments * Prior academic work * mostly running on simulated networks * ongoing IETF work * LAMPS working hard on pq topic * new pqc@ietf.org mailing list * Uri: support for the effort on standards-track. * Scott: round 3 parameter set might be smaller. * Sofia: we will check and correct. * Ben: length limits in TLS, how many packets can be sent in initial QUIC connection. * Thom: test of how many bytes/latency involved (on Cloudflare blog). Although TLS spec might allow many megabytes, but some active implementations assume much smaller. QUIC has anti-amplification, which might require padding of initial messages so that the server can send back the full, large certificate chain. * Sofia: QUIC WG has been looking into it, but no formal tests yet. * ekr: network dynamics vs implementation issues: servers would have to advertise they accept these pq anyway. but more concerned about roundtrip times, which would be unacceptable with very large certificate payloads. "all pretty horrifying" * Sofia: some hope of smaller sizes in the call for new algorithms. * mt: changing to have to send two packets would be a major problem. would prefer lighter security target in order to fit into a single packet. less concerned about anti-amplification because they can send non-critical packets. 10k maybe okay, but not 10k's. * Sofia: participating in the NIST workshop would be great. PQ workshop may be co-located. * mt: sending a message in two packets will break servers that operate statelessly. a major problem. ### A Flags Extension for TLS 1.3 - last outstanding PR (Yoav Nic) {#a-flags-extension-for-tls-13---last-outstanding-pr-yoav-nic} * Is it possible to define a request that has one flag set, but the response has "real" data. Is that a legitimate use? PR says "no" but did not get much feedback. * Consensus is to merge PR that says only possible response to a flag option is a flagged response, not content.