Minutes IETF102: tls
minutes-102-tls-11

# 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: SLIDES:
https://datatracker.ietf.org/meeting/102/materials/slides-102-tls-ietf-102-tls-wg-chair-slides-10]

Salz: 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, or 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 publish 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 Nygren: we want to make sure people don't even think about 1.1 1.s0 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]

Nick: "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 Hoyland: would be nice that authenticators would be unique, makes the
analysis easier.

Mike Bishop: already have a requirement 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]

Paul: "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 (and 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 with syntax and semantics in
separate update RFC, or 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. There 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. 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 include 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?]

Barnes: Extension advertised in ClientHello... Trying to authenticate but not
bind yourself to [something]. 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.

Chris: we may decide to just put this back in the editor's queue and address
later. Shall we hum?

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.

Chairs: We're going to postpone this discussion to Thursday. Will probably pull
from the Editor's queue but will revisit.

## Connection ID (Ekr)

[SLIDES:
https://datatracker.ietf.org/meeting/102/materials/slides-102-tls-dtls13-and-connection-id-00]

Ekr: 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 is 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. 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 (Ekr)

EKr: Putting extra flight bits in there, not my ordinary preference.

MT: 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.)

Ekr: has new connection ID message. If we increase sequence number, new CIDs
are pointless. Idea is to always have Connection ID. PNE uses same function as
QUIC: use some of the ciphertext as input to PRF

MT: Are we planning to cipher the epoch?

Ekr: 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 (Nick Sullivan)

[SLIDES:
https://datatracker.ietf.org/meeting/102/materials/slides-102-tls-delegated-credentials-00]

Nick: not a lot of work done at the last IETF. Motivation: reduce exposure of
certificate private key to memory disclosure vulnerabilities. History of
compromises 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, and used to finish TLS connection.
Client validates these delegated credentials. They have a simple structure.

Nick: implementation status: Several people 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.

Nick: QUESTION 1: whether we should move to Object ID for IETF security OR use
ExtendedKeyUsage

David Benjamin: EKU usage cases

Nick: 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.

Nick: Proposal 3: (by Christopher Patton) in case of RSA, whole list of cipher
suites. Proposal is to pick up one ahead of time (you can only use one then).
This makes analysis simpler. Can manufacture more than one DC. A 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

Nick: Proposal 4: draft supports TLS 1.2, 1.3 -- we should 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

Nick: 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 (Jonathan Hoyland)

[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)
Jonathan: 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.
        If I have two branches, they can have two different authentication
        properties (wouldn't suggest this, but it ensures it doesn't break).

Mike: 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

Ekr: how am I supposed to know which one should I link to?
        A. I mention number

Ekr: What makes me check it?
        A. Draft says you have to check. If you include it in the response,
        that means you checked.

Ekr: 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

## 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 (Russ)

Russ: In TLS 1.3, initial handshake authentication is based on certificate and
signature, and DH shared secret drives the key schedule. In a subsequent
handshake, authentication is based on resumption PSK, and the key schedule is
driven by the resumption PSK or the resumption PSK plus and an additional DH
shared secret. Proposal: add an additional option to the initial handshake to
include an external PSK that is combined with the DH shared secret. Want to do
this for quantum protection; the external PSK must be distributed out of band.
An attacker with a quantum computer needs to learn the external PSK to crack
the key schedule. (See ladder diagram of where this would fit.) Syntax: a
boolean; the TLS extension is present or not. If the extension is negotiated,
the client and server agree to include the external PSK in the key schedule.
Presently language in TLS 1.3 precludes PSK when certs are used. The external
PSK wouldn't be used for resumption, just initial handshake. Group of TLS peers
would need the same PSK and identifier. If the quantum computer comes along,
the attacker would have to compromise one of the members of the group to obtain
the 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 (Richard Barnes)

Barnes: TLS PAKE. Difference is a rev of the draft, fixed typos. Bind to SPAKE2
originally now we just have any given PAKE protocol. It's 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?

Ekr: 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 (Chris Wood)

Chris: 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 (Chris Wood)

Chris: 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, etc. 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.

Chris: We propose a 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. There's some DNS pieces, TXT
record under _esni.example.com. Clients send a new extension, EncryptedSNI. Key
derivation: client keyshare has to match the group from DNS, clientshare from
ClientHello. Potential for downgrade attacks.

Chris: 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).

Chris: 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.

Chris: Update on interop: Got this into NSS! client of BoringSSL and picoTLS.
Browsers include firefox, WIP 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

Chairs: Call for WG adoption. hum for adoption. Yes: mucho hums. No: no hums.
We will adopt this doc.