IETF 120 - TLS WG

7/24/2024

Notes by Laura Bauman

Planned Agenda
Administrivia and Status - chairs - 5 min
8446-bis update - Turner - 10 min
TLS Formal Analysis Triage - Deirdre - 25 min
TLS Hybrid Design - Douglas - 15 min
ML-KEM-only - Deirdre - 15 min
WK-ECH Well-Known ECH - Stephen - 15 min
TLS Frozen - Rich - 5 min
SSLKEYLOG for ECH - Yaroslav - 5 min
Extended Key Update - Hannes - 5 min
Trust expressions - David - 20 min

ML-KEM-only

• Dierdre:

  • Laying out a new document for pure-PQ ciphersuite for TLS 1.3
  • similar but not the same as the hybrid design since it is PQ
    only
  • Not asking for mandatory to implement, but wants it written down
    so that people that wish to may begin to implement particularly
    MLKEM768 and MLKEM1024.
  • MLKEM512 not currently in there, not opposed to adding it though
  • Client sends encaps key, server replies with ciphertext

  • KEM shared secret is input to Handshake Secret derivation

    • same as ECDH

  • Why can't you just add a codepoint?

    • because there is no document saying how to do this yet

  • Should this be recommended or MTI?

    • No, just optional

  • What about PQ signatures?

    • no, this is easy. Signatures are hard.

  • Isn't this too early?

    • no, considering long timelines for adoption.

  • Just use hybrid?

    • some users cannot use hybrid or do not wish to use it or do
      not want to do more than one PQ transition

• Queue:

  • Hannes Tschofenig: Likes it because it feels liek a natural
    extension and it is not a modification to how TLS works.
  • Yoav Nir: Push back on some FAQs, you can just get a codepoint,
    specification does not need to be an RFC. That said, just
    because you can doesn't mean you should. Having a working group
    document is the right thing. Should have a proposed standard or
    informational. Nobody will be forced to implement.
  • Kyle Nekritz: if we don't do this now then it is unclear what we
    are waiting for. Wants to see the 512 codepoint which helps fit
    things into one packet.
  • Dan Harkins: wants 512 too
  • Paul Wouters: This provides a particular KEM with a description
    of how to use generic KEM in TLS. Would like to see those split
    out: how to use KEMs (no specific KEM) as an RFC and then the
    particular KEM could get a particular codepoint
  • Chris Wood: Think we have confidence in our design, but caution
    against having a high level of confidence in the
    implementations.
  • Turner: Everyone seems supportive can we just adopt?
  • Paul Wouters: discussion later on particular codepoints
  • Deirde: There are some KEMs that are much larger. I would write
    a lot more words for generic KEMs to cover all of those cases.
    This will delay the document landing even though people want to
    start using KEMs now. But delaying to do that will gum up the
    works
  • John Gray: Could be helpful to separate it out because we know
    more KEMs are coming.
  • Deirdre: I can make it very specific and restrictive and say
    that all your stuff need to fit in the TLS KeySchedule. But that
    will make people angr.
  • Richard Barnes: clarifying on potentially splitting doc. Let's
    just do it with ML-KEM since we know how to do that now since
    there is demand now. Lets solve first and then abstract.
  • Sophi Schmieg: Thinks one doc is the better solution.
  • Paul Wouters: Why do you need a doc and not a codepoint then?
  • Deirdre: Cause we don't have a document about just a KEM.
  • Paul: Still feels like the doc is doing two things
  • Dennis Jackson: Doing the safe thing for the combiner and
    getting this moving is the right thing. Doing the simplest thing
    is a good way forward.
  • Deirdre: I do not oppose a general KEM idea since it will be
    going into the TLS 1.3 key schedule, but there is more to get it
    done

TLS Hybrid Design

• Dierdre:

  • Hybrid design is the general way to combine two algorithms
  • 20% of fresh negotiations are using hybrid PQ tls 1.3. X25519

  • The generic hybrid doc looks good and will not be including IANA
    entries itself

    • any new codepoints will have their own documents

  • Two instances

    • NO RECOMMENDATION or MTIs

8446-bis update - Turner

• addressed errata (thanks Ben Smyth)
• #1390: do we make X25519 MTI?
  • PR: A TLS-compliant application MUST support key exchange with
    secp256r1 (NIST P-256) and X25519

    • is this even relevant for this document? since this is just
      supposed to be for clarifications.

      • Hannes Tschofenig: is this for clients and servers both?
        (YES). I am not working in IOT anymore, but this makes
        it tricky when you only have hardware support for one
        alg.

        • not relevant --> trying to decide if we are going to
          consider this change?

      • Results of poll: Not make this update now. We will
        confirm on the list.

Formal Analysis Triage Panel Update

• Deirdre:

  • FATT: Formal Analysis Triage Team lol

    • Why? Call for RFC 8773bis there was a lot of noise about
      some formal analyis on the change to TLS 1.3.

      • this change was about you can do both certificate and
        psk based auth. This hadn't been modeled before.
      • They were always assumed to be disjoint.
      • Spurred discussion on how we get discussion and input on
        the tweaks we make to TLS 1.3 and how they may interact
        with the properties established for prior/original
        version

    • Mechanism: triage, then maybe analyze

      • we have a triage panel (rotating group of volunteers to
        give preliminary triage)
      • duiring proposed changes to TLS 1.3 and whether they
        need updated or new formal analysis
      • Also done before last call
      • Panel also gives an estimate of the scope of work such
        an analysis would entail

    • If the wg agrees to proceed, the formal analysis triage
      panael consults on farming out the meat of the analysis work
      (to their teams or students they supervise, etc.)

    • Triage panel membership can be refreshed on a regular
      schedule or on an as-needed basis.
    • We do not want to limit feedback to just IETF people that
      can't attend or monitor the IETF mailing lists.

    • What Kind of formal analysis?

      • Not just Tamarin
      • Panel can suggest specific approaches
        • existing work
        • new models
        • pen and paper
        • etc.

    • Goal: Maintain the high degree of cryptographic assurance in
      TLS 1.3 as it evolves

    • First try: 8773bis [HARD MODE]

      • it had already gone through an adoption call and last
        call.
      • people hadn't successfully got formal analysis through
        that process

      • We went to the triage team

        • recommended more clarity in the document on intended
          security goals
        • further anlysis to check especially the
          authentication properties, symbolic analysis tools
          would be suitable

      • Document hasn't changed yet

      • Russ and Usama collaborating on ProVerif model?

        • Russ: disagree that this is where we are at now. You
          posted the FATT results, questions were asked and
          there was no response.
        • Usama: Was a bit suprised by this because the last
          we heard was that the chairs needed to give a
          consensus call on whether we need to proceed with
          this. Also a bit concerned about the process. The
          reviews were isolated and the summary was not clear
          on how it all came together. I have concerns on
          transparency in the process and would prefer for it
          all to happen on the mailing list or see it
          separately not a summary (LB: I think?). Wants to
          see exactly what each reviewer suggests and would
          have liked to be part of the process itself.
        • Deirdre: Good feedback, our goal is to make this
          more like an academic review. In Academia the
          responses are all collated by reviewer even when
          anonymous so we can do that. We do want things to be
          transparent and that's why we collated it all and
          added to the IETF mailing list, but we want to allow
          them to stay anonymous without having them to put
          their claims on the public internet. From there on
          it should be the working group discussion of that
          professional feedback
        • Britta: agrees a lot of these colleagues won't want
          to be named, but wanted to see list. Wanted to see
          what type of analysis might be asked about. The
          mentioned approaches are all very different and
          wants a cohesive view. Something to be said about
          reviewers being willing to come forward. I was one
          of the reviewers on this draft and consulted several
          other people and we were not confident that the
          analysis was worth it.
        • Deirdre: we would love to hear that cause we didn't
          have a thing to cite that said this change was
          valid.
        • Britta: that's where transparency comes in.
        • Dennis Jackson: Generally agree that transparency
          would be helpful. Want to cleanly separate these two
          bits. This was a formal analysis of this draft and
          what we need to see to feel more comfortable about
          it. The analysis group should give there feedback,
          but the analysis panel should not have sway with the
          IETF process. Don't think there is only going to be
          a small number of people on the panel to make
          comments, so anonymity may not actually be that
          effective. The formal analysis won't know much about
          the IETF process: just the security questions:
        • Usama: wasn't clear whether we needed computational
          analysis or what? The panel did not seem to give a
          clear suggestion and left it to the working group to
          decide. The panel should recommend if not decide
          whether symbolic analysis is needed. They said that
          wasn't even discussed. We are in a loop of the
          chairs are waiting for something and we are waiting
          for the chairs.
        • Deirdre: This is hard mode because if we had to take
          this feedback into an adoption call or working group
          last call. We haven't made a consensus call yet
          because we are doing this out of the process. To
          Dennis, having two settings where one is on WG and
          documents and the other is about security changes to
          TLS 1.3 to establish whether we need formal
          analysis, computational analysis, or proof to be
          confident.
        • Rich Salz: This isn't modeled after an academic
          review of papers. This is more like collaborative
          research so I think the model is wrong. Triage
          implies to me that the model is wrong. They are not
          deciding anything. They are making an opion on
          whether something else should be done. If they
          aren't able to put their name on it then I don't
          think it is worth listening to their opinion. We
          have collaborated with cryptographers and other
          experts in the past and none of that was anonymous.
          Think anonymity goes against the spirit of the IETF.
        • Paul Wouters: Think it is unclear whether the FATT
          operates under the Note Well.Seems like we are
          putting a blocking process from outisde the IETF. We
          should fold this into proper IETF process. If it is
          just outside feedback then we should make that
          clear.
        • Hannes Tschofenig: Thinks anonymity is the wrong
          model here. When he asked for outside feedback for
          OAS (?) the researchers were not not interested in
          anonymity: the opposite. They don't need to be on
          the mailing list, but we should fine tune this.
        • Jonathan Hoyland: Not a member of the FATT, but did
          a formal analysis in tamarin of TLS 1.3.
          Specifically to this draft, the authentication
          properties that we prove are no longer respected
          with this change. I think this does have to be
          blocking which will involve a lot of busy work
          redoing the proofs.
        • Dennis Jackson: The core of the problem is that
          people are willing to volunteer their time to do
          security research, but not get involved in IETF
          things. If we give people a transparent safe space
          to do the research and then the WG do the IETF
          things separately.
        • Deirdre: has had people run away from this process
          because they volunteered to provide their expertise
          and then got dragged into internet arguments. So I
          understand the desire to separate the procedural and
          security open discussion, but I am aware that people
          with valuable opinions need to be protected from
          internet flame wars.
        • Turner: we clearly dropped the ball for 8773 bis, we
          will talk with the authors and figure this out. Mea
          culpa trying to do the process and define it at the
          same time.

      • No further consensus calls... yet

WK-ECH Well-Known ECH - Rich

• ECH keys are updated regularly and must be published to DNS

• A "Zone Factory" polls origins via WK resource

  • if they changed, it test them (keys) for validity
  • Publishes updates to DNS

• Process (diagram)

  • TLS Client looks up A/AAA, establishes TLS session with Frontend
  • Zonefactory (DNS operator for backend)

• Changes:

  • many editorial
  • xml2rfc v3
  • Greater compliance with HTTPS SVCB

  • IANA considerations

    • register well-known "origin-svcb" entry
    • Add JSON Service Binding registry for top-level elements

  • Security Considerations

  • ?

• Issues

  • #18: Any I18N issues? i don't think so

    • Turner: anyone with I18N have expertise to review?
    • Ali Saleh: I can review that

  • #21: Architecture for intermediaries

    • "Things" in front of the origin: e.g. load-balancers with
      different protocols; HTTP gateways

  • #16: One origin can "claim" to speak for others;
    under-specified? (MT's early review)

  • #14: Is this still ECH specific?

    • probably not
    • Would probablly be useful for boostrapping service B entries
      draft
    • Anyone have opinions? Should we make this more generic?

    • Stephen Farrell: Getting an answer to this would be good for
      this meeting. Think Rich and Ben share, but my opinion is
      that just doing this for eCH then we should go about this.
      If other people want to suse this for other things in
      service B records.

      • Turner: if it is not TLS then I am going to kick it out
        of this group

    • Stephen: nobody has asked for anything besides ECH. We need
      to decide this soon.

    • Rich: think David was talking about using it for key-shares
      in his draft
    • Arnaud Taddei: think it would be good to make an exploration
      on what might be coming. I'm not against generalizing, but
      we should have a group look at what could happen here so we
      can decide whether to generalize it or not.
    • David Benjamin: The key_share prediction is another place
      where this would be another place we could use this. This
      DNS record will be a place where others will want to put
      things in there. Think having some clear way for when your
      DNS provider and your host provider are different to
      coordinate with useful info. What is the most useful thing
      for server operators? Not sure what other people want to do
      with it.
    • Benjamin Schwartz: this draft is already completely
      generalized. The draft has no text related to ECH or TLS at
      all, but all the motivations (4 so far) have all come from
      tLS. This draft can serve any purpose, but the only cases we
      have are TLS. Not telling anyone where to put this draft,
      but it is useful we should put it somewhere and change
      title.
    • Stephen Farrell: Disagree, involves checking ECH keys. The
      isue becomes thinking through who should kind of have
      control of those. If and when the key_share thing is ready
    • Turner: show of hands for whether we should expand the scope
      to address tls features?
    • Stephen: it already does. It is a json thing. It doesn't say
      you can't. If the key share stuff wants to use it then they
      can add stuff there.
    • Rich: change the title
    • Turner: anyone speaking against?
    • Kyle Nekritz: thinks saying it is only for TLS things seems
      to be a pretty arbitrary and strange thing
    • Turner: how long do we wait?
    • Paul Wouter: If this is generally applicable and do a last
      call then send to dnsop.
    • Benjamin Schwarz: this is already a completely general thing
      that can move things that have nothing to do with TLS. It
      already does because it transports the service parameters,
      but people in charge of those didn't want the draft because
      those change so unfrequently. This is future proof for later
      params.
    • Arnaud Taddei: from an architecture perspective, ?

TLS Frozen - Rich - 5 min

• Remove duplicates from UTA WG use-tls-13 draft

  • remove the bullet list from the intro
  • remove the security considerations
  • add text that says "nothing here applies to DTLS 1.3"

• IANA will stop accepting registrations for any TLS parameters except
  TLS exporter labels, TLS ALPN PRotocol IDs

• PQ also: say no pq stuff for 1.2
• The document is only 60 lines and sends a message that we are not
  changing 1.2 except for critical security fixes
• Chris Patton: Clarify? Rich: this is jsut all the text that is left
• John Gray: will people add pq stuff to 1.2 instead of updating to
  1.3?
• Rich: well we aren't the protocol police
• John Gray: Is this going to be blocked? Rich: There is a sentence
  that says none of this applies to DTLS 1.3
• Watson Ladd: Ship it
• Paul Wouters: does this apply only to RFC required for IANA
  registrations.
• Rich: There are no first come first serve registrations for DTLS.

SSLKEYLOG for ECH - Yaroslav - 5 min

• SSLKEYLOG is a useful troubleshooting tool for TLS handshakes
• with ECH we lose that capability

• Challenges of TLS troubleshoting with eCH:

  • inspecting ECH
  • Troubleshooting ECH
  • ?

• Proposed soln:

  • ECH_SECRET label to log HPKE shared_secret
  • ECH_CONFIG label to log ECHConfig
  • Outer ClientHello Random as keys for ECH_SECRET and ECH_CONFIG
  • Inner ClientHello Random for the rest of the session as long as
    ECH was accepted

• Prototype implementations:

  • NSS

    • very straightforward as shared secret is a part of HPKE
      context

  • BoringSSL

    • required additional callback

  • Wireshark

• Visibility into ECH

• Confirming server acceptance

  • can look at magic bytes and compare to computed ones

• Visibility into the rest of the session cause we can caluclate the
  correct keys

• Questions?

  • What do you think about the problem?
  • What do you think about proposed solution
  • Should this work be adopted by the working group?

• Stephen: hated SSLKEYLOG. For everything that we do to improve
  security and privacy of TLS are we going to break it? I say we
  shouldn't make this easier and I don't think it is particularly
  relevant for developers. Layering violation in the way you are
  logging this. Wouldn't necessarily work everywhere. Against.

• Kyle Nekritz: think this is a useful logging toodl. Think it would
  be easier if we stuck with outer client random as it is basically
  just an identifier.
• Christopher Patton: useful tool, would have been helpful while
  workin gon ECH. If we already have SSLKEYLOG we should have for this
  as well.
• Hannes Tschofenig: disagree with Stephen. It is a debugging tool.
• Turner: leaning toward adopt, we will take to the list.

Extended Key Update - Hannes - 5 min

• Status: version 2 with re-design based on feedback from Brisbane
  meeting

• New design uses:

  • flags extension to negotiate the feature
  • message exchange for sharing the key shares
  • separate exchange to trigger the update of traffic secrets
  • "too_many_extendedkeyupdate_requested" alert
  • forward compatible with hybrid exchange and key_share extension
    and ML-KEM (not in doc yet)
  • there is a migration path

• Message Flow

  • ExtendedKeyUpdate after initial key exchange flow

• Next Steps

  • Call for adoption?

  • Additional work ahead of us:

    • formal analysis

      • working with Usama

    • Prototyping

• Yaraslov Rosomakho: think it is extremely important work since TLS
  is getting more adoption outside of traditional setting (e.g. SSH 3)
  would benefit greatly to have the ability to rotate keys.

• Jonathan Hoyland: have you attempted to implement the tls flags bit
  of this because I tried for a different feature and had a bit of a
  rough go of it.
• Hannes: not yet, will work on it. Will reach out to you to ask about
  it.
• Dennis Jackson: In the draft there is a bit where the keys need to
  be deleted when you need to move to the next keys. And that is a
  SHOULD and not a MUST. Could it be a MUST and not a SHOULD?
• Hannes: they should be deleted asap, it is probably a mistake
• Dennis: it would be good to provide clear criteria on what to do in
  this situation (particularly in the DTLS case)
• Hannes: some timeout
• Turner: objections on running working group call on adoption? No.
  Ok, will confirm on list

Trust Anchor Negotiation

• Bob Beck, David Benjamin, Devon O'Brien

• Trust Anchor Negotiation

  • Quite a few changes since Prague. Based on initial feedback that
    the lengthy on list discussion made it hard to
    follow/participate. We wanted summarized in supporting
    documentation.
  • 1. Explainer document on trust anchor negotiation at a high
       level
  • 1. PKI transition strategies doc and goes through a bunch of
       transitions that are relevant to TLS and how they may be
       impacted by trust anchor negotiation

  • Alternate approach:

    • The trust expressions draft was lengthy, so we made a
      separate draft for trust anchor IDs that is more concise

  • Since Brisbane, until a couple weeks ago, convo was about
    surveillance and privacy considerations. We added security
    considerations to both drafts.

  • Surveillance scenarios can be very subtle and have drastically
    different outcomes based on assumptions.

• TLS Parameter Negotiation

  • TLS does this for ciphersuites. Goal: select best cipher suite
    in common
  • Also happens with curves and basically every other feature.
  • We do this to support evolution of more secure options.
  • Negotiation allows the internet to move forward.

• Trust Anchor Negotiation:

  • Client trusts some CAs ("trust anchors")
  • Server has some certificates available
  • Goal: Select certificate based on what client trusts

• Client Diversity:

  • TLS client ecosystems are already diverse
  • Root programs in the "same" PKI make independent decisions

  • Older and newer clients diverge over time as PKIs evolve

    • older clients may trust a smaller older set of roots and may
      not be able to update

  • Cosntrained devices (e.g. IoT) often cannot update at all

  • Some clients (e.g. mobile apps) pin to particular CAs or keys
  • Servers must somehow navigate this

• PKI Agility

  • TLS client diversity can be useful

  • Old and new clients diverge as PKIs change, but PKI changes are
    necessary for user security:

    • Rotating root keys
    • Removing CAs
    • Adding CAs

  • Performance -- avoid lowest common denominator

    • up to date clients can trust short-lived "intermediate"
      directly
    • Avoid sending unnecessary cross-signs when CA is already
      trusted
    • Parallel issuance when cross-signs are expensive or not
      viable
    • Even more tailored designs (e.g. Merkle Tree Certificates)

• Security vs Availability

  • If servers cannot meet diverse client needs, security and
    availability conflict:

    • Security: PKI changes are sometimes necessary for user
      security
    • Availability: server msut satisfy all supported clients

  • Example: Client removes CA1, supports CA2. Server also needs to
    support toher clients which only support CA1. When availability
    and security conflict, availability usually wins:

    • Security winning would mean servers drop support for some
      clients (won't really happen)
    • Availability wins: PKI changes needed for user security do
      not happen or are delayed

  • User security is the casualty of this conflict.

  • negotiation gives another option: servers use CA1 and CA2,
    depending on the client.

• Trust Anchor Negotiation

  • Goal: Enable servers to handle client diversity so server
    availability does not conflict with PKI security and performance
  • PKI transitions do not impede overall server availability
  • Root programs can make timely security decisions on behalf of
    users

  • Minimize operational burden for server operators

    • more server operators than CAs and root programs
    • ACME extensions for CAs to send multiple certificates
    • PRefer fewer mechanisms that cover the whole problem

  • Minimize bytes on the wire, especially as we transition to PQC

• Bob: Two Approaches

  • Problem: certificate_authorities (RFC 8446) is too large

    • X.509 names are large (average 100 bytes per name)
    • Some PKIs have many CAs (hundreds)

  • Two approaches:

    • Trust Expressions
    • Trust Anchor IDs

• Trust Expressions Recap

  • Client express cA lists relative to named "trust stores:

    • Trust stores are maintained by root programs
    • Client cna express deltas, but not as flexible for fully
      arbitrayr CA lists

  • prioritizes minimizing server burden

  • Con: not as expressive for clients

• Trust Anchor IDs: Short CA Names

  • Prob: X.509 names are large
  • Soln: make shorter
  • 1. Allocate a trust anchor ID for each CA
       * we use relative OIDs under Private Enterprise Numbers
       (RFC 9371)
       * About 5 bytes per CA

  • Configure in server with CErtificatePropertyList

  • [missed]
  • [missed]

• Trust Anchor IDs: Server Offer, Client Select

  • Prob: still cannot send full trust anchor list-- client
    bandwidth and privacy constraints

  • soln: use an eCH style retry after server offers its list of
    trust anchors -- available server certificates are fewer and
    less privacy sensitive

    • client may send empty trust anchor list, or some subset
    • server msends trust anchors of available certs in EE
    • on mismatch or err, client selects aanchro
    • [missed]

  • [missed]

• Trust Anchor IDs: Push to DNS

  • Retry flow adds latency
  • list available server certificates in DNS
    • Definie tls-trust-anchors SVcParam for HTTPS/SVCB records
    • Client uses SvcParam for initial prediction to trust anchor
    • [missed]

• Trust expressions

  • only expresses CAs lists relative to root program "trust stores"
  • works analogously to client certificates
  • servers use static config from CAs
  • CAs and root programs need contiuous coordination via "trust
    store manifests"
  • [missed a lot]

• trust anchor IDs

  • supports arbitrary CA lists
  • short ca names apply to both client and server certs, retry is
    only possible with server certificates
  • [missed a lot]

• Security Considerations

  • We have enumerated the various scenarios discussed on list

    • Technical considerations have been added to the drafts
    • Policy consideration/speculation have been added to a
      supporting document
    • We have performed an initial analysis of discussion points

  • If there are missing scenerios or analysis we want to
    fix/address

• summary

  • two proposed approaches to address PKI transitions in TLS
  • We'd liek feedback from WG on preferred approach
  • Next steps:
    • discussion
    • hums for preferred approach
    • call for adoption

• Paul Wouters: Also had this problem of certificates being too large
  in IKEv2, chose to do hash of CA and then if you really only want 5
  bytes you could truncate. Why use OIDs?

• Devon: it was a first attempt at truncation. It is also managing the
  authority? This could be tracked and managed by a diff authority.
• Alessandro: For trust anchor IDs: put stuff in DNS what could
  possibly go wrong? You say that trust expr most o fthe complexity is
  between root program and the CA. I guess this is fine if you have a
  root program already, but what if I am a mobile app and want to do
  pinning. I woul dneed to communicate with the CA?
• David: Trust expressions does not handle this as well. You could use
  the existing certificate_authorities extension since you just need
  to add a couple.
• Alessandro: for client certs, we already do the
  certificate_authorities for that and even if there are only a few
  those bytes still add up.
• David: Trust anchor ids still work for client just not in retry case
• Christopher Patton: Is the retry mechanism significantly different
  from what we have for ECH today? [i don't think so] how much of a
  lift would this be for implementors? [it is out of TLS for full
  retry] I think trust anchor ids is headed in the right direction
• Benjamin Schwarz: how do yo see this handling horrible enterprise
  TLS interception scenarious.
• Devon: can you clarify?
• Ben: client has been configured with a CA that is only used locally
  and outside of the root program.
• David: in that kind of environment to trust a terminating proxy, the
  "server" (terminating proxy) always sends you that certificate. So
  they don't have that problem in the first place.
• Ben: what does the client send?
• David: you don't have to have all your roots participate in this
  design. In trust expressions you would send the ones in your browser
  without some clear signature from the user otherwise that is a
  privacy leak
• Ben: would that involve a change in the api between operating
  systems to know which roots are public/private.
• David: there are typically system apis to tell the difference. In
  trust expression, we already have to do stuff related to this. We
  assume the clients know something related to what roots it trusts.
• Kyle Nekritz: Thinks it is important that we do something here.
  Slight preference for trust anchor ids with concern for retry
  mechanism
• Watson Ladd: Think we need an interim to discuss these things
  because there are a lot of details we haven't touched on.
• Turner: think we are trying to figure out which direction to go
  looks like trust anchor ids.
• Andrew Chen: think trust expressions makes more sense. Retry aspect
  of anchor IDs worries me.
• Stephen Farrell: think we should think through what the long term
  interaction of TLS and PKI should be before starting on deciding
  between these aproaches.

• Show of hands: 24 in favor of TIDs, 6 in favor of TE, 12 no opinion.

  CHairs Note - when the meeting ended the mic queue was not completly
  drained