TLS WG @ IETF 115 - 10 November 2022

Administrivia

• Overview of document status for WG documents

Scribes: Florence D and Mike Ounsworth

8446bis (EKR) - 30 min

https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/

Planning to quickly rev 8446 to fix some issues. Has taken about 18
months so far.

EKR merged lots of PRs, check the change log if you'd like to.

Remaining PRs:

• 1275 - Unsolicited Extensions - You're not meant to be able to send
  request extensions in EE, text is being clarified to make this
  clear.
• 1270 - Key Update Limits - Pulling in text for 9147, need to decide
  balance of consistency v. clarity. If you feel strongly check the
  change log.
• 1269 - Errors for Bogus Tickets - Propose just closing PR
• 1231 - Acknowledge RFC 8773 - EKR is going to review this text,
  would like someone else to review it too.
• 1223, 1224 - Clarify HRR Behaviour - It's a bit unclear but it's an
  improvement over 8446, no better suggestion. Propose deferring
  these.

Martin Thomson: Do all of these things and then we'll be done. Don't
want to make substantive changes.

Rich Salz: Is it feasible to document the ambiguities? EKR: Very
difficult.

EKR will finish these things.

Sean Turner (ST): Want to move this to Internet Standard. Leaning on
group to ensure that features are all implemented. I'll write an small
interoperability review.

David Schinazi: If IPv6 is a full standard, then TLS 1.3 can be too.

8447bis (Sean Turner/Joe Salowey) - 20 min

https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

RFC 8447 currently obsoletes RFC 8447 - this is confusing, hard to
review, hard for IANA. Updating would be easier. Any objections?

Sean Turner: This document is instructions for IANA, so do whatever is
easier for them to understand.

EKR: Is the AD happy?

David Schinazi: In general I prefer obsolete documents. But here it's
not the document that matters, it's the IANA website, so whatever makes
sense for them.

Paul Wouters (AD): Normally the problem with diff documents is that
people don't want to have lots and lots of changes. That doesn't apply
here.

Joe: Ok, we'll work on clarifying the bis in the coming weeks.

Rich Salz: It's not just IANA who cares, this is simpler, we can follow
directions either way.

Marked reserved values as 'D'.

Martin Thomson (MT): Who chooses the SHOULD NOT or the MUST NOT? Joe:
Depends on the context. These are only applicable in certain contexts.
MT: It's odd to use a registry in this way. Maybe put in something about
the linked documents. Joe: I agree. Rich Salz: +1 to MT.

Changes to Registry Policy - new text.

MT: Is this every state transition? It could say "IESG approval is
necessary for all other state transitions"

Richard Barnes: I reviewed this and I convinced myself it covered all
state transitions.

MT: Would prefer it if it was a bit clearer.

Joe: So you're saying the last line should be "For All State Transitions
IESG approval is Required"

MT: All other.

Joe: Yes, that would be simpler.

Paul Wouters (individual): Is there a reason we're using single letters?

ST: No strong reason, just saves page space.

David Schinazi: Exporter labels registry is currently specification
required. Given it's a string registry with infinite room can we just
make it expert review required?

Joe: I thought it was only specific prefixes that were extension
(specification required?) ...?

EKR: You can just generate a random UUID and put things after it.

EKR: I'd be supportive of this change. I wonder if we should make it
even easier. Maybe we could just say that a document is required.

ST: It is sufficient just to have an internet draft that's publised but
never progresses or something from another standards body. It just needs
to be public.

DS: This is why I was thinking expert review. There's no point in saying
you have to publish something and that thing can be empty.

ST: Submit a PR and we'll review it.

Yoav Nir: Let me check standards action requires IESG Approval.

Paul Wouters: This came up in another meeting, can a draft be
specification to satisfy a "specification required"? A draft gets you
early allocation, either the draft expires and your early allocation
expires, or the draft becomes a RFC. Need to check this with the rest of
the IESG.

ST: We've looked at this before: even an expired draft is still public
in the archives, so that should be fine.

EKR: We're discussing a change to the current policy, which means we
wouldn't require a full description of the protocol at all. Trying to
figure out some way of encouraging people to document protocols without
requiring them to do so.

ST: We're currently trying to document first come first served, David is
asking if we required expert review. This would be a new policy.

DS: You can add a note saying that a specification is highly encouraged.

EKR: Purpose of expert review is to make sure people don't register
inappropriate strings.

Joe: EKR can you put in a PR? EKR: I'll do that.

Obsolete Key Exchange (Nimrod Aviram) - 15 min

https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/

Draft deprecates RSA Key Exchange and Static FFDH. Limits FFDHE to
groups >=2048 bits. Discourages ECDH (static).

One open issue. FFDHE groups - clients can't verify group structure
because it's too expensive. One suggestion without consensus is
deprecating FFDHE entirely. Authors suggestion is to have no requirement
around group structure. Question of how much this matters - web clients
have disabled FFDHE, while email clients won't very group structure
anyway. This issue is the only thing holding up the draft. Strongly
recommend moving forward with this compromise.

ST: Is there anyone who disagrees with the way forward?

Daniel Gillmor (DKG): Who is opposing deprecation here? Don't
opportunistic clients have concerns about other TLS KEXs? If you're
doing opportunistic TLS surely RSA is better than nothing. If the
opposition to deprecation is coming from opportunistic clients then we
can have a not about that.

NA: The main opposition came from Viktor Dukhovny - his concern was
about SMTP clients. Many use custom groups because of advice that was
given to operators of SMTP servers.

DKG: Ok, so you're saying the argument is that as long as we have FFDHE
to fall back to we can deprecate RSA?

NA: Yes.

DKG: Can't we say that only if the alternative is falling back to
cleartext then falling back to FFDHE is ok. No one on the web will fall
back to cleartext.

EKR: There are browser settings now that attempt HTTPS frst and fall
back to HTTP. We would not be interested in supporting these cipher
suites, we want to same policy for every connection. What is the scope
of this? If we deprecated FFDHE entirely how many connections would go
from encrypted to plaintext.

NA: Email clients would ignore deprecation, but if they didn't then
according the Viktor much of the email ecosystem would become plaintext.

EKR: Rather than coming up with complex recommendation, we should write
what people should do, and if people are behind then they can not move
yet. We should make the right recommendation.

DKG: If SMTP servers who only do FFDHE are looking at stats and
connections go to cleartext when we deprecate FFDHE then they'll have to
implement ECDHE.

DKG: That is, if we deprecate it explicitly, and some opportunistic SMTP
clients do adopt the deprecation, they will fall back to cleartext. This
is a clear signal to the ecosystem that these insecure KEX mechanisms
are in use in places where we want better outcomes.

EKR: I can't see us applying different properties for opportunistic v.
non-opportunisitic mode.

MT: Should say opportunistic connections can do whatever they like.
Let's leave a carve out that if you don't care about security as a
baseline then we don't care what you do re. this particular requirement.
NA: So the suggestion is have stringent requirement for
non-opportunistic clients, and otherwise do whatever.

Yoav Nir: Suggestion is deprecate FFDHE entirely.

Nimrod Aviram: So the suggestion is that for non-opportunistic
connections deprecate FFDHE entirely or do all checks that make it safe
(e.g. group structure). For opportunistic connections you can do
whatever you want, or you can fall back to FFDHE.

Kyle Nekritz: I'm worried about this carve out, where does it end? What
is this issue special?

NA: Agree with Kyle. This leads to the question of what counts as
opportunistic.

David Schinazi: Strongly opposed to this opportunistic thing. We should
think about deprecating FFDHE altogether again.

ST: Let's do a consensus call.

DS: I would propose: option 1: do we have consensus on deprecating
entirely?

MT: I think we should have option 1: Deprecate FFDHE entirely, option 2:
deprecate FFDHE without good groups. Don't think we need to do anything
about opportunistic case. The RFC on opportunistic encryption already
allows opportunistic clients to use less secure options than ideal if
that's the only option.

NA: Think we're going towards deprecating FFDHE entirely.

Stephen Farrell (SF): I don't disagree with David, but I know that some
people do, including Viktor and he usually has good arguments.

ST: We'll do a poll but we will then take it to the mailing list.

SF: Option 2 "only use good groups" doesn't get us anywhere because it's
the SMTP community that want FFDHE and they usually use custom groups.

EKR: Opposed to (MT's) option 2 because I don't think it'll work. I
would strongly prefer not to have a weird, explicit opt out. Carve out
for old clients is in the opportunistic document and also they can
ignore us.

DS: Sometimes it's hard to update old boxes, that doesn't mean we
shouldn't publish the RFC.

EKR: The purpose of this document is to tell people in our ecosystem
that they should be updating. So if we have an explicit carve out for
opportunistic people will think they don't need to change.

Yoav / Paul (in jabber): deprecate != disable. Anyone running ancient
software is allowed to just ignore our recommendations.

Let's do a poll.
Poll: Do you support deprecating FFHDE?
39 participants.
Raise Hand: 34. Do Not Raise Hand: 5

Chairs will take this to the list.

DKG: I don't think this poll is sufficient to say that the mood is
"deprecate entirely".

ST: Yes, this gives us somewhere to start.

DKG: Want a strong deprecation statement of some sort.

URI for publishing ECHConfigList (Stephen Farrell) - 15 Min

https://datatracker.ietf.org/doc/draft-ietf-tls-wkech/

Ben Schwartz and Rich Salz now co-authoring.

draft-01 tries to cater for a wider range of ECH deployment
architectures.

Background: ECH normally relies on HTTPS records to publish ECHConfigs
in the DNS. Want to avoid cutting a pasting public keys into zone files.

New version, technical summary: In this version the zone factory speaks
to the origin (rather than client facing server(CFS)) Zone factory
creates resource records, fetches values from origin. Origin needs to
sync with CFS which creates the ECH Configs. Use JSON template to create
HTTPS RR.

This version makes using a CNAME a bit easier, you can create a JSON
blob that eventually turns into a CNAME. Nice but feels a bit dangerous.

There's a multi-CDN example. Needs a bit more work but it should work.

Other details. DNS TTL needs to be less that HTTP freshness lifetime.
Also, ordinary web clients shouldn't use this in place of HTTPS RR.

TBD. Exact template matching rules, IP requirements, support for
non-HTTPS protocols.

SF: Is this a better version that -00?
ST: This is better, better to have wider deployments in mind.

Ben Schwartz (BS): The template is an attempt to balance competing
desires. We want to stick to only talking about ECH and information you
need to know to use that. But on the other hand, your zone factory is
going to create DNS records that have a bunch of other stuff in them. So
we've said let's focus on ECH here, and leave the other stuff to the DNS
side.

David Schinazi: I like the more conceptual approach. Is you intent that
browsers always query this well-known on all websites. BS: The browsers
don't know about this at all. The querying client here is the zone
factory, which is a component of an authoritative DNS server.

SSLKEYLOGFILE (Martin Thomson) - 10 Min

https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/

SSLKEYLOGFILE - a file format designed to capture secrets. Used for
debugging in TLS stacks and tools.

Standardising this needs a home. Currently the documentation for this is
in the NSS source docs, pretty hard to find. Idea is to take this
documentation, put it in an RFC and give change control to the IETF.

Question: Does the WG want to take this on?

ST: My understanding is this would be informational.

MT: It's an interoperability thing, there's an argument for making it
standards track.

DS: Yes.

Nalini Elkins: Support this work Any plan to say that browsers should
implement something like this?

MT: No, there's a lot of debate about this. It carries risks to security
and privacy, so people are concerned and there are lots of stacks that
don't implement it and that's ok.

SF: To what extent does the current documentation contain warnings?

MT: Documentation just has a file format. The draft has warnings.

SF: Supportive of documenting this if there are enough warnings.

Deb Cooley (DC): How's this different to PKCS#8?

MT: We don't do anything in terms of protecting secrets. If you're
operating in FIPS mode you just can't do this.

DC: So I don't care.

Richard Barnes: This is more like a stream format so you can pipe data
straight into wireshark.

Poll: Sense of the room: Is there interest in working on
draft-thomson-tls-keylogfile i-d in the TLS WG?
33 participants.
Raise Hand: 28. Do Not Raise Hand: 5

Other Stuff

Stalled/Expired WG I-Ds

• Batch Signing for TLS

David Benjamin: I don't have time to work on this now. If someone else
wants to pick it up then it's a cool mechanism but I'm not going to do
anything.

ST: Will let the process do its thing.

MT: Suggest marking this draft as abandoned.

• Semi-static DH Key Establishment for TLS 1.3

EKR: I'm interested, come back to me when 8446bis is done.

Encrypted Client Hello

Andrew Campling: Anyone that missed the ECH deployment considerations
side meeting on Monday evening can catch the recording of the session at
https://419.consulting/encrypted-dns/f/ech-on-the-side. (Sorry about the
quality of the sound but I think you should be able to pick up the key
points).