Minutes interim-2021-tls-01: Thu 12:00
minutes-interim-2021-tls-01-202104011200-00

# TLS Virtual Interim 3
## April 1, 2021 - 1900-2000 UTC

Notes by Christopher Patton <cpatton@cloudflare.com>

## Agenda

ECH Issues - https://github.com/tlswg/draft-ietf-tls-esni/issues

## Reused HPKE context: https://github.com/tlswg/draft-ietf-tls-esni/issues/397

* Current spec doesn't allow use of the "single-shot API" of HPKE.
* sftcd: maybe defer this until we've settled the HRR issue
* UNRESOLVED: Resolve after 407

## Compression: https://github.com/tlswg/draft-ietf-tls-esni/issues/398

* stfcd: "ech_outer_extensions" adds implementation complexity. Is it
  necessary to be this general necessary?

* Ben Schwartz: Worth "re-spelling" the mechanism? Maybe the inner is the
  same unless an extension is present, maybe add a means to remove from
  the inner.

* CPatton: not too difficult for the server; optional for the client

* CWood: has been implemented and is interoperable

* MT: NSS implementation had some bugs, but it was simple programming;
  could go either way

* stfcd: I'm in the minority, so it's ok for the chairs to override me.

* RESOLUTION: Close this issue. (If someone comes up with something simpler,
  then it seems like people are open to that. File a PR!)

## Acceptance signal: https://github.com/tlswg/draft-ietf-tls-esni/issues/399

* Acceptance signal adds complexity: client may need to re-process SH. This
  causes implementation complexity.

* Relaxation: Just use CHInner.random as the secret to derive the signal. Hash
  over the entire SH (in particular the server's key shares).

* CWood: Active "don't stick out" attacks suggest we don't understand whether
  this relaxation is safe. Proposal: punt until we have security analysis.

* MT: Not a problem if cipher suite preferences are the same in
  CHInner / CHOuter.

* David B.: Weird interaction with PSK. PSK is inserted in the key schedule
  before the decision is made. Have to back up and change this on retry.

* MT: PSK/ECH interaction is not fully understood.

* UNRESOLVED: Resolve after 407 and we have an analysis to support the final
  design.


## Validating ECHConfig.public_name: https://github.com/tlswg/draft-ietf-tls-esni/pull/413

* Issue 405: Stuff from DNS can find its way into CHOuter. Do we restrict the
  public name to host names, or allow IP addresses? Should we exclude IPv4?

* CWood: What goes in the public_name of ECHConfig? How to construct CHOuter
  using this information? (Ties into issue 396 (whether public_name MUST match
  CHOuter.server_name).)

* Ben Schwartz: Spend one byte and have public_name be a server name, as in
  RFC6066. We may need more extensibility in the future, so let's add it now.

* MT: Distinction between DNS names and IP address is what matters. Don't spend
  the byte. The only real issue is the ambiguity between DNS names and IPv4.
  Dan's suggestion is the right one: the name in the public_name is what you
  validate.

* stfcd: public_name is *a* name you can use to validate the fallback cert.
  I agree.

* CWood: Let's rewrite the text so that it talks about how to construct CHOuter
  using the identity that will be validated.

* Ben Schwartz: I don't like the idea of trying to parse this string in different
  ways. If what we mean is "identity that is validated", then don't we need
  identities as defined in the X509 spec?

* RESOLUTION: Take CWood's suggestion (rename as public_identity instead of
  public_name), GeneralName (5280)?

## MUST include outer name: https://github.com/tlswg/draft-ietf-tls-esni/issues/396

* RESOLUTION: Same resolution as 413.

## HRRInner/Outer: https://github.com/tlswg/draft-ietf-tls-esni/pull/407

* David B.: HRR is a disaster, but we're stuck with it.

* Issues:

    * HRR in current draft applies to CHInner and CHOuter. We "patch" this in
      the spec by guiding clients towards keeping HRR-sensitive parameters the
      same in CHInner and CHOuter.

    * "Split mode". If backend server sends a cookie, the client doesn't know
      whether to send it to client-facing server or backend server.

    * "don't stick out" attacks apply to current design.

    * Current design contradicts RFC8446.

* MT:

    * Happy to solve the "cookie" problem by having client-facing server and
      backend server do something out-of-band.

    * HRR forgery attack on "don't stick out" is acceptable

    * Complexity is unacceptable.

* David B.: Matching HRR-sensitive parameters in CHInner / CHOuter is trickier
  than MT appears to think.

* stfcd: Can we just accept that some edge cases are failures?

* MT: The rule should be that the client has the same inner / outer preferences
  for any parameter that impacts the handshake secret. This should solve the main
  problem.

* EKR:

    * Three types of complexity: implementation, spec, and analytical.
      CHInner / CHOuter was an attempt to solve analytical complexity.

* Chris P.: HRRInner / HRROuter solves future composition issues with ECH.

* Ben Schwartz: Reasonable to demand that key_shares is the same, it's much harder
  to demand that client-facing server and backend server have the same preferences. 

* David B.: PROPOSAL: Someone write down CHOuter / CHInner matching rules that
  gets rough consensus.

* MT:

    * Cookie thing: It's a corner case. Let's ignore it.
    * The rules we have for CHI/CHO matching are correct, modulo contradiction
      with 8446.

* stfcd: Give me the numbers! How common is HRR?

* Chris P.: For Cloudflare it's rare, but not neglible.

* David B.: Also rare for Chrome. But the more important point is that the server
  can't guarantee it doesn't need to send HRR. (We got HRR wrong!)

* EKR: Is encrypting HRR complex?

* MT: Because HRR is rare, we're talking about code that is not gonna get thoroughly
  tested.

* EKR / David B.: Back and fourth on how we landed on the HRRInner / HRROuter.

* David B.: Can we reduce the complexity of the current PR?

* Ben Schwartz: Backend server can generate always generate a SH.random tag.
  (acceptance signal?)

* UNRESOLVED: We will put together a design team to iron out HRR. The team
  will propose a solution in a month at the next TLS interim.