Using TLS in Applications (UTA) WG

IETF 112, Friday, November 12, 2021, Session III, 16:00-17:00 UTC
https://meetings.conf.meetecho.com/ietf112/?group=uta&short=&item=1

Meeting materials: https://datatracker.ietf.org/meeting/112/session/uta

Chairs: Leif Johansson, Valery Smyslov
Responsible AD: Francesca Palombini

Note takers: Hannes Tschofenig, Rich Salz, Peter Saint-Andre

Agenda

• Administrativia (jabber scribes, note takers), Note Well, IETF Code of Conduct, Agenda bashing
  Chairs (5 min)

• draft-ietf-uta-rfc7525bis
  Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
  Peter Saint-Andre (15 min)

• draft-ietf-uta-rfc6125bis
  Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
  Rich Salz (15 min)

• draft-ietf-uta-tls13-iot-profile
  TLS/DTLS 1.3 Profiles for the Internet of Things
  Hannes Tschofenig (15 min)

• Open Mic
  (5 min)

• Closing
  Chairs (5 min)

  Minutes

  Chairs present the Note Well: https://www.ietf.org/about/note-well/

  Note Takers: Hannes; help from Rich, Peter

  Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (Yaron Sheffer)

recent changes

• two versions since IETF 111
• closed most of the issues, but a few open issues remaining
• authors think the draft is stabilizing; please read the draft
• the section about differences from 7525 are especially important
• added text about ALPN
• incorporated text from I-D about deprecating MD5 and SHA1
• more details about integrity and confidentiality limits
• require extended_master_secret

TLS supported versions

• new in TLS 1.3
• benefits unclear for TLS 1.2
• feedback requested

TLS 1.2 downgrade protection

• a good idea

RSA-PSS

• this is a SHOULD in TLS 1.2
• what do we say about certificates? PSS doesn’t seem to be used in the wild

obsoleting key exchanges

• individual I-D discussed in TLS WG but not adopted yet

“consumer” documents

• 100+ RFCs reference BCP 195
• vast majority cite in a generic way
• typically no specific details
• a few exceptions but nothing of concern

Peter Saint-Andre: the concern now would be about documents outside the IETF; we’ve done our due diligence; we should handle that in WGLC

Leif: there was discussion in SAAG - is there any syncronization we should be doing?

Yaron Sheffer: That is more a question for the ADs.

Leif: should we be talking with TLS WG etc.?

Francesca: I’ll check with Ben and review the notes/recordings

Leif: TLS is essentially doing work on recommending crypto; Hannes made comment about TLS is mostly focused on web applications of TLS

Ben Kaduk [Sec AD]: Nothing terrible to say now; ADs taking an action item to coordinate.

Peter Saint-Andre: we did cross post last time around so that coordination happened.

Valery Smyslov: t it sounds like the customer review is the big topic

Yaron: actually we completed that work but need to tie up a few details and report back

Valery: what about the dependency on the kex document?

Peter: people are always deprecating things, so we can publish but something else could be deprecated right after we publish; need to do occasional updates.

Jonathan Lennox: we might want to point people at, say, the IANA registry and TLS WG, where future deprecations could happen

Joe Salowey [TLS WG chair]: I think the intention is adopt the kex document. As to the broader coordination question, we should definitely have a chat among the chairs and ADs. We’re working toward the same goals.

Valery: We’ll do that.

Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (Rich Salz)

recent changes

• lots of editorial fixes
• simplified wildcards (only the complete leftmost label allowed)
• replaced section about pinning with brief text
• we now assume that TLS SNI is in use (this wasn’t the case when RFC 6125 was written)

items for discussion

• proposed text about multiple identifiers, posted to the list

• authors will try to create a better (i.e., shorter!) title :-)

  • Valery strongly supports this

• Rich and Peter will sync on any other desired changes

• Rich and Peter will review consumer documents (as the authors have done with 7525bis, see above), see https://www.arkko.com/tools/allstats/citations-rfc6125.html

• Rich: if someone doesn’t support SNI in their referencing doc, that’s a bug on them, not in 6125bis.

  TLS/DTLS 1.3 Profiles for the Internet of Things

CCM_8 troubles

• integrity limits of CCM_8 are quite low because of reduced tag size
• this introduces a DoS surface - very careful risk evaluation is needed
• unfortunately it’s the only MTI ciphersuite in CoAP
• how to proceed? we could let developers decide, but they might not be in a good position to decide well
• just not recommend CCM_8?
• which ciphersuite(s) should we recommend instead?
• possibly CCM (tag is 16 bytes)
• GCM with SHA 256? but it’s not in hardware
• CHACHA/Poly 1305?
• wait for results of NIST competition for lightweight crypto?
• Valery: from my understanding of John’s analasys CCM_8 is not a complete disaster
• John Preuss Mattson: frequent re-keying in CCM_8 doesn’t help, but 64-bit MAC option should help; I will post more in CFRG in the coming weeks
• Hannes: nothing wrong in that analysis, the question is how to set the parameters; hard to provide good advise to developers, there are also factors like the security of the underlying link layer (e.g., LoRaWAN vs. Wi-Fi)
• [scribe misses a bunch of stuff]

relaxing initial timer values

• Note that DTLS 1.3 handles things differently
• change RTO from 9s (RFC 7925) to 3s (RFC 2988) or 1s (RFC 6347)?

long connections without renegotiation

• industrial IoT applications often use long connections
• hard to provide recommendations that apply to all IoT technologies

examples of client EE cert IDs

• what do people use in their certificates?
• might want to stick to EUI-64, but there are suggestions in GSMA eUICC and OMA LwM2M too and we might want to provide such examples
• we don’t want to be exhaustive in our examples
• we’ll never agree on one true identifier
• Valery: is there any connection here to rfc6125bis?
• Hannes: 6125 is about the server side and we should reference that, but this issue is about client side

Open Mic