TLS WG Agenda (Tuesday 3/18)

Administrivia (30min)

• Note Well
• Scribe: Laura Bauman

• Status

  • Mail List Moderation

    • FAQ Updated
      • PRs welcome
      • Monthly reminder: keep it professional

  • FATT Status

    • Queue of 5 drafts
    • -dtls-rrc is up for review

-ech (aka -esni) & -scvb-ech

• in IETF LC, almost there and then people showed up with things they
  want to do

• -ech (aka -esni)

  • ARTART review: "ready with nits"
  • DNSDIR review: "nits and minor qs"

• -scvb-ech

  • DNSReview ready to go
    ## -rfc8446bis and -rfc8447bis {#-rfc8446bis-and--rfc8447bis}

• -rfc8446bis

  • AD comments addressed
  • IETF LC expected after IETF 122

• -rfc8447bis [missed see slides]

PQ-Related I-D Adoption Calls

• we will run adoption calls for the PQ cipher suite I-Ds, which have
  been discussed
• we are NOT picking an MTI in these I-Ds!!!
• this list may grow.

other drafts

• deprecate-obsolete-kex pinned on -rfc8447bis
• -hybrid-design

• -keylogfile

  • strong support to adopt -keylogfile
  • both -keylogfile & -ech-keylogfile completed WGLC
  • consensus was to yank -keylogfile back from RFC editor and merge
  • second WGLC for (merged) -keylogfile completed
  • plan to PUBREQ today
  • CHAIRS: do you have strong opposition to not adopt?
  • stephen farrell: are we just doing a yes/no decision or evaluate
    points on ml?
  • Chairs: trying to move it foward
  • stephen farrell: moving it forward in a binary manner?
  • Chairs: yes, as is
  • stephen farrell: doesn't seem responsible based on messages

• Do you object to moving forward with the publication of the
  SSLKEYLOG draft?

  • yes: 4
  • no: 22
  • no opinion: 18
  • chairs: get in queue or come to mike if you disagree strongly?
    • stephen farrell: 4 said objected, 19 said go forward. Thinks
      objection on list have not been addressed. Don't think the
      WGLC included responses to points raised.
    • Rich Salz: Did respond to people that said their is concern.
      Pointed out existing flaws. Think it is useful and don't
      think it is going to cause key leaks.

Working Group Drafts

-rfc8773bis FATT Report

• Britta Hale
• Main idea of draft: Use PSKs in TLS (including early data) with
  claimed resultant quantum resilience
• FATT: talking to external researches. WG still needs to make
  decisions. External review of draft with people that have done
  analysis on TLS

• Requested reviews from researchers in the topic area

  • includes people that have worked on cryptographic computational
    and symbolic analysis areas
  • all reviewers have pub work related to TLS

• Reviewers: 4, some IETFers and some not

• Report aggregates review comments, quoted directly when possible and
  minimally paraphrsed when not.
• responses are semi anonymous, quotes not attributed to direct
  reviewer
• reviewers have been asked to review the aggregate report

• REMINDER: do not contact reviewers directly. If they want to engage
  in IETF process they would (and have been invited).

  • they are already spending time reviewing something they may not
    normally do usually until after a draft is published

• any questions/comments should go to Liaison for clarification

• Net Summary:

  • high level of consensus across reviewers
  • Positives: 8773 is unlikely to introduce vulnerabilities or need
    for analysis for traditional TLS (against trad attacker)

  • Netatives: more severe concerns about 8773 under the claims for
    quantum resilient security

    1. Claims about authentication were not substantiated
    2. Claims about quantum resilient security were not
       substantiated given lack of clarity in PSK generation (not
       specified - would PSK from trad sess suffice?)
    3. Sec guarantees under adversary are unclear when PSK reuse is
       allowed across sessions and use types
    4. Grounding for claims under TLS security (or general
       security) under a quantum adversary
    5. It is not clear if the guarantees meant are for hybrid or
       not and, if hybrid, what form

  • Recommendation of of 2 courses of action recommended:

    1. reduce or remove the motivation and security claims in the
       document on quantum resilience of 8773, such that the
       functional inclusion of a PSK is an offered functional
       attribute only and not a point of reliance for content
       confidentiality.
    2. keep the security claims and current motivation, which
       includes protections from quantum adversaries. This option
       requires analysis

• in both cases should improve clarity on the auth properties and
  [missed]

• Draft has been revised since reviews

  • PSKs do not provide authentication
  • requirement for quantum-resilient PSK generation and
    distribution methods
  • still leaves 3 on concerns list

• Author pref to keep both PSK resuse and group options

• Corresponding FATT rec: obtain analysis and match security claims in
  the draft to corresponding provable security model

• Chairs: 3 broad categories to move forward

  • we can publish as is
  • we can revise draft to reduce security claims or remove protocol
    options
  • we can keep doc as is and wait for formal analysis

• Russ Housley: Do security considerations adequately describe how
  these protocols are actually used. To get the TLS security
  attributes you would need to get pairwise PSKs. I think allowing
  both and documenting what you get with pairwise or group PSKs.

• Ekr: raise a question that is process oriented. In the environment
  where we have a CRQC basically this reduces to TLS based KEM. So
  when this draft was published, it provided security when we had no
  other options besides PSK. Now we have algorithms that provide the
  same privacy/security properties even in the face of CRQC. The thing
  we actually want them to do is not this PSKs anymore since we have
  these algorithms.
• Russ: Of course we now have algs that we didn't have when first
  done. But other WGs are using this mechanism but they want the
  properties they get with PSKs in the near term before infrastructure
  is in place to use newer algorithms. Has this adequately documented
  the security features you get when a CRQC comes along and you are
  using a PSK? I think it does
• Ekr: Does the TLS wg think people going to do this. I think the
  question to ask is are the TLS wg going to do this instead of PQ
  algorithms? Making this a standard is making this a thing we "want
  to do"
• Chairs: this is already an RFC. Used in a EAP method.
• Britta: what does the wg want to do? We also need to answer
  questions regarding the security considerations currently on the
  draft. What is the security if you are using a group key and key
  reuse? Normally we have a lot of key separation. It is not clear
  that we are clearly stating guarantees
• Russ: PSK only appears in handshake
• Britta: can put the PSK across different sessions
• Daniel Shiu: Did the expert group have any estimates about suitable
  tooling or how long an analysis might take?
• Britta: recommended analysis is net outcome. Some months is probably
  a good estimate of how long it would take.
• Ben Schwartz: Would the technical contents of the draft change based
  on the results of analysis or would the properties under quantum
  analysis just change? If the analysis came back relating to quantum
  attack on this approach would we change the protocol or just
  document those deficiences. It sounds like it might be the latter.
  If it is already being used in EMU. Maybe the right path forward
  maybe change flavor of text.
• Ekr: if it reveals deficiencey it should be repaired. What is at
  stake here? Is there a strong motivation for why this needs to be a
  standard. There is another status that indicates we thought this
  over but don't think it is great. We could take that option. Is
  there a reason I am missing this needs to be a standard?
• Chairs: in EMU it's a down ref
• Russ: EMU WG why is this experimental so started work to get to
  standards track. I think it greatly improved the security
  considerations. If we want to proceed with informational that is ok
  with me.
• Ekr: I want to leave people with a clear understanding of the TLS WG
  recommendation of what to do in this situation for PQ resistance. I
  think that rec is using PQ key exchange algorithms not using PSKs in
  a lot of settings.
• Britta: These are good discussion points. Maybe it is worth seeing
  if this is something people are really looking to pursue as a
  standard.

• Chairs: questions for WG

  • do we want to publish draft as is?

    • yes: 9
    • no: 14
    • no op: 18

  • should we publish the doc as informational without any changes?

    • yes: 9
    • no: 19
    • no op: 16

  • should the WG revise security claims?

    • yes: 30
    • no: 1
    • no op: 4

  • should the WG leave as is and wait for formal analysis?

    • yes: 5
    • no: 18
    • no op: 4

Request mTLS

• Jonathan Hoyland
• similar to what I presented last time, but hopefully with more
  consensus on what I am after

• Distinguishing bots is hard

  • many bots come from pub clouds
  • bots distinguish themselves by setting a user agent

• not secure at all

• CertRequest lets us identify bots

  • if we incorrectly send a cert request to a human they probably
    won't know what to do

• Proposing that we add a tls flag in tls flags extension that just
  says " I am configured with a certificate" and server can safely
  send a cert request

• why adopt here?
  • feedback that the exact semantics of the flag are unclear
  • discussion on use cases
  • drive tls flags by providing a use case
    • unary encoded (smaller your point number the smaller your
      extension)

Discussion

• David Benjamin I think the flag makes sense, but we should be clear
  what the flag means. How to evaluate the question of whether we have
  a client certificate is messy because of weird UI things. We
  evaluate whether any of the client certs make sense.
• Jonathan: normal human people browsers should never implement
• DB: that implies you would have a bot auth flag not a send cert
  request flag
• Jonathan there is a case where browser isolation may want to use it
  (still don't consider that a human driven browser)
• DB: currently phrased the wrong way I think
• J: think we should adopt hae a convo on ml
• Ben Schwartz: don't get it. you have a user-agent.
• J: only get user agent after tls connection complete
• J: there is post handshake auth and I don't like it's security auth
• Ben: can you do this at the connectio nlevel?
• J: tried it and it didn't work because of connection pooling.
• Ben: don't get why it needs to happen upfront like this
• J: saves perf
• Ben: does that matter? those are batched jobs
• J: no, can't tell google bot to double cost
• Ben: disagrees
• Ekr: your assumption that in the case of google bot what are they
  going to offer?
• J: spiffy cert from own CA
• Ekr: is google actually going to do that? I think this is a
  threshold question. Need. some web crawler to show someone wants to
  do it
• Andrei: microsoft, not really oppposed to this as a general perpose.
  If I implement it how do I document that the general purpose client
  doesn't use it?
• J: just don't offer it?
• Viktor: useful in email space for DANE when a client may want to
  tell the server to prompt the client to send the certificate.
  Supports this and thinks it can be useful outside of the web.

Thursday, March 20, 2025 @ 02:30-04:30 UTC

Note-taker: Rich Salz

Administrivia (30min)

• Note well reminder, meeting tips,
• Agenda bash: Jonathan H: New folks here, mTLS adoption? ???@Google:
  We are evaluating it

-trust-anchor-ids (David Benjamin)

• Draft 0 published, no changes, collecting decision/dicussion points,
  overview of what the current list.
• No discussion

PAKEs

-draft-bmw-tls-pake13 Laura Bauman
Martin: Could we make the PAKe info yet another keyshare? Avoids
explosion of options, but not if multiple RTTs are required
EKR: I think better to think of it as like a PQ thing, not another
elliptic curve
Jonathan: we should have a standard way of injecting key material into
the handshake; if you model the PAKE as a DH exchange, probably no
symbolic analysis is needed.
Scott: The PAKE in the draft has a weakness, emphasize it in the
security considerations
Hannes: PAKEs have a bad history in TLS, please elaborate more about the
use cases
Laura: yes, seems different this time.
David Schinazi: I think the issues are tractable, authors's affiliation
gives thoughts about use cases
Tommy: I think this can be important to have a simple standard for this.

Richard Barnes: Cisco is also looking at using this
Slight general discussion from about who would use this, we're looking
at it, etc.

-draft-guo-pake-pha-tls Liang Xia
DavidBen: this is not the same as TLS 1.3 post-handshake authentication;
this seems to be using a stream protocol and doesn't have to use TLS
Jonathan: Don't use exporters and channel binding, this should be
independant of TLS
EKR: Suggest you take use-cases to secdispatch, as this is generic
Nick: explanation of previous draft which wasn't adopted
Scott: can't just use HTTP, need to bind the PAKE to the lower-layer
traffic (such as tLS 1.3 bindigns); needs analysis

Discussion
Show of Hands (SoH): Should we work on a mechanism fore PAKEs in TLS?
Yes 38 No 4 no opinon 15
SoH: Do you support doing PAKE in TLS handshake? Yes 43 No 6 no opinion
19

Martin: now sure having the PAKE operate at the TLS layer is the right
thing to do
Stephen: I don't think doing PAKE in a TLS handshake is a good thing at
all
RichardB: Multiple vendors are interested in shipping this
Stephen: History is they are "cute" but "not useful"
CAW: Things have changed

SoH: Do you support doing PAKE in TLS post-handshake? Yes 6 No 27 No
opinion 33

Sean: Based on the results, we will soon do an adoption call for the
first draft.

Implicit ECH Nick Sullivan

EKR: Could "not stand out" by making ECH universal
Alessandro: (sorry, missed the point); some back-and-forth with Nick
Stephen: Don't hold up ECH but we should look at this. Nick: Agreed

ECN public Names Martin Thomson

Yaroslav: Some use the public name for (initial) routing. Censors could
DNS lookup outername and block if not "real" Martin: Make sure all
entities have access to the keys.
Ben: (sorry)
Nick: What about grease? Martin: use the public bname that you have;
Nick: So Ben's point is accurate; MArtin: yes.
Stephen: We sholud work on this problem after ECH is done/deployed
EKR: How much info does the attacker already have from the IP address?
Think about that when we work on it

Anonymity sets in ECH Jonathan Hoyland

Ben: Fallback flow doesn't require client/server to remember any crypto
material. So just remember your keys
Dennis: Fallback doesn't rely on DNS and we should preserve that
property
Martin: Ben's wrong, have to remember public name (retrieved via DNS)
and you need SPKI. Don't think there's escaping knowing such info, so
that server key rotation works. Public name must be something you can
get a TLS cert for.
Ben:
Deirdre: rerandomizer is PQ safe, re-hashing isn't. jonathan: I can
easily model the first one tho
Nick:

Existing ECH document progress not being changed; we will discuss these
things on the list.

Identity Crisis in Attested TLS (Muhammad Usama Sardar)

Mike: interesting use case, a TLS cert and a DevID cert. Is this useful?

Jonathan: already done 9261, just use that.
Hannes: attestation is not an x509 cert and that is required by 9261
jonathan: oh dang. (ed:could not use "rats")

Please continue discussion on the list.