Minutes IETF109: tls
minutes-109-tls-00

# TLS @ IETF 109

## Logistics

### Time

Tuesday, November 17, 2020 (+07), 14:30-15:30

### Meeting Information

Meetecho (a/v and chat):
https://gce.conf.meetecho.com/conference/?group=tls&short=&item=1

Audio (only):
http://mp3.conf.meetecho.com/ietf/ietf1086.m3u

Etherpad (virtual blue sheets and notes):
https://codimd.ietf.org/notes-ietf-109-tls

## Agenda

### Administrivia

- Virtual Meeting Tips
- Note Well
- Virtual Bluesheet
- Note Taker
- Jabber Scribe
- Status

## Status
1. Certifcate compression -- refer to RFC 8478 instead of
   RFC 8478bis to remove a reference dependecy that is
   holding up pulbication.
2. Deprecate 1.0/1.1 -- last call
3. DTLS edits
4. ...

## DTLS CID
* Pointed out during security review:
    * Encoding of input to MAC is not injective
        * Confusion around the boundary between the CID
          and plaintext
* Not clear what the impact is, but it makes the protocol
  hard to reason about.
    * Not an issue for TLS 1.3
* Poposed solution:
    * length-prefix the CID
* Objections?
    * Benjamin Kaduk (no objection): Do we need a new
      code point?
        * Answer -- ??
    * Hannes Tschofenig (no objection): At various times
      we've changed the AD and MAC due to the potential
      of an attack, but without a concrete attack or a
      formal anlaysis to say either way.
* NO OBJECCTIONS.

## TLS ECH
* PR#353: Derive accept confirmation from handshake
  secret
    * Objections?
        * Eric Rescorla (no objection): Is the attack
          that this prevents in scope? We don't yet
          have a clear threat model.
        * Chris Wood (no objection): Points to GH issue
          regarding the threat model for "don't stick out".
          (https://github.com/tlswg/draft-ietf-tls-esni/issues/354).
    * NO OBJECTIONS.
* PR#352: Use the same HPKE context between the two CHs
    * NO OBJECTIONS.
* PR#316: Require HRR-sensitive parameters match in CHOuter/CHInner
    * Objections?
        * Jonathan Hoyland (no objection): Does this increase the
          risk of fingerprinting?
            * It's not clear.
    * NO OBJECTIONS.
* PR#360: Define new code point for CHINner indication
    * NO OBJECTIONS.
* Issue#326: Authenticate ClientECH parameters via AEAD encryption
    * Objections?
        * DKG (no objection): does this require fancier
          interconnection between the fronting server and
          the backend in split mode?
            * No it doesn't.
    * NO OBJECTIONS (NEEDS TEXT).
* Issue#358: ECH contradicts second ClientHello consistency
  requirements in RFC8446
    * EKR: The solution isn't to strike "and present in the
      HelloRetryRequest", as David Ben suggests. The intent
      of the rule is that you're not supposed to change
      things the server didn't tell you to change in the HRR.
    * Chris Wood: We might just punt until after ECH-09.
    * David Ben.: There is a compat isssue in the wild!
      "LibreSSL breaks if you change an extension they don't
       recognize. :-("
    * NEEDS DISCUSSION.
* PR#313: Replace record-level padding with handshake-level
  padding
    * Chris Wood: Punt the server-side padding story until
      after ECH-09.
        * Objections?
        * NO OBJECTIONS.
* Issue#354: "Don't stick out" considerations
    * Chris Wood: Let's make this (one of the) main issues
      to discuss at the next interim.

## Interop targets
* Steal QUIC's methodology for coming up with implementation
  targets
    * Target a draft, but an implementation might target a
      draft + some PR.
    * Goal: continue development on the spec while allowing
      implementors to follow along.
    * Objections?
        * EKR: Please don't target particular sets of PRs