[TLS] ech/esni - theoretically some inner CH's wouldn't fit...
Hiya, The CH in TLS has a 3 octet length. The payload in ECH has a 2-octet length. Hopefully that'll never matter but it's an inconsistency I don't recall coming up before. (Apologies if I've forgotten, or if I've missed something in 8446 that forbids bigger CH's.) I'm fine with just leaving it as-is, or with noting in the text that you will suffer this problem (and many others;-) if you want to use a CH that's that long, or with moving to a 3 octet length for the payload. Cheers, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-ietf-tls-external-psk-guidance-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Guidance for External PSK Usage in TLS Authors : Russ Housley Jonathan Hoyland Mohit Sethi Christopher A. Wood Filename: draft-ietf-tls-external-psk-guidance-02.txt Pages : 15 Date: 2021-02-20 Abstract: This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) version 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. It discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions. It provides advice for applications in various use cases to help meet these assumptions. It also lists the privacy and security properties that are not provided by TLS when external PSKs are used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-guidance/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-external-psk-guidance-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-guidance-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ech/esni - theoretically some inner CH's wouldn't fit...
Moving to a three-byte length wouldn't do anything: extension bodies themselves have two-byte lengths, so any longer lengths within an extension is just a waste. (To that end, because every field in a ClientHello has a two-byte length, the longest possible syntactically valid ClientHello at all is 2 + 32 + 32 + 1 + 32 + 2 + 2^16-2 + 1 + 2^8-1 + 2 + 2^16 - 1 bytes, which is doesn't fit in two-byte length, but nearly does. And, in practice, implementations may impose length limits on incoming messages beyond that to avoid DoS risks.) On Sat, Feb 20, 2021 at 3:19 PM Stephen Farrell wrote: > > Hiya, > > The CH in TLS has a 3 octet length. The payload in ECH has a > 2-octet length. Hopefully that'll never matter but it's an > inconsistency I don't recall coming up before. (Apologies if > I've forgotten, or if I've missed something in 8446 that > forbids bigger CH's.) > > I'm fine with just leaving it as-is, or with noting in the > text that you will suffer this problem (and many others;-) if > you want to use a CH that's that long, or with moving to a 3 > octet length for the payload. > > Cheers, > S. > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"
Sean and Joe: The revision to address Ben' comments has now been posted. I believe that all WGLC comments have been addressed. I think this document is ready to go to the IESG. Russ > On Jan 22, 2021, at 3:27 PM, Russ Housley wrote: > > Ben: > > Thanks for you review and comments. > >> We've only had one review in response to the last call so far, I'd like to >> see a few more reviews of this document before moving it forward. Are there >> any volunteers who can commit to a review in the near future? >> >> I've reviewed and have only a handful of minor comments. >> >> Section 1, opening: Password and key comparison seems rather weak, unless >> low-entropy PSKs are used. If low-entropy PSKs are a focus, then perhaps >> make this clearer, which will simultaneously strengthen the comparison. > > There is guidance on many other aspects of security as well. Maybe this > comparison is setting inappropriate expectations. Maybe the first paragraph > should avoid the comparison altogether. I suggest: > >This document provides guidance on the use of external Pre-Shared >Keys (PSKs) in Transport Layer Security (TLS) version 1.3 [RFC8446]. >This document lists TLS security properties provided by PSKs under >certain assumptions and demonstrates how violations of these >assumptions lead to attacks. This document also discusses PSK use >cases, provisioning processes, and TLS stack implementation support >in the context of these assumptions. It provides advice for >applications in various use cases to help meet these assumptions. > >> Section 4, "These keys do not provide protection of endpoint identities (see >> Section 5), nor do they provide non-repudiation (one endpoint in a >> connection can deny the conversation)": Perhaps relate to other modes of TLS >> which do provide such protection. > > I suggest adding: > >Protection of endpoint identities and protection against an endpoint > denying >the conversation are possible when a fresh TLS handshake is performed. > >> Section 4, "If this assumption is violated": The assumption has two aspects, >> namely, "each PSK is known to exactly one client and one server" and "these >> never switch roles." The following paragraph explains what happens if each >> PSK is known to more than one client, server, or both. But what if roles are >> switched? Whilst maintaining the former aspect of the assumption. > > The only cases where that I have come up with where it is possible for the > client and server to swap roles (like TLS between to mail servers) do not > actually cause any trouble. If a browser and a web server got confused about > their roles, it could be a problem, but that does not seem likely to happen > either. Does anyone have a suggestion here? > >> Section 4, "then the security properties of TLS are severely weakened": >> Perhaps add "as explained below" or similar. > > Good idea. Added. > > Russ > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Weekly github digest (TLS Working Group Drafts)
Issues -- * tlswg/draft-ietf-tls-esni (+3/-2/💬12) 3 issues created: - Update to HPKE-08 (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/387 - Fixed-length values should probably be fixed-length (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/386 - PSK usage sticks out (by cjpatton) https://github.com/tlswg/draft-ietf-tls-esni/issues/384 3 issues received 12 new comments: - #384 PSK usage sticks out (4 by chris-wood, cjpatton, davidben) https://github.com/tlswg/draft-ietf-tls-esni/issues/384 - #380 Related Privacy Leaks suggests too strong of a correlation across resumption (4 by cbartle891, chris-wood, davidben) https://github.com/tlswg/draft-ietf-tls-esni/issues/380 - #378 Naive outer_extensions decoding is a DoS risk (4 by cbartle891, chris-wood, cjpatton, davidben) https://github.com/tlswg/draft-ietf-tls-esni/issues/378 2 issues closed: - Related Privacy Leaks suggests too strong of a correlation across resumption https://github.com/tlswg/draft-ietf-tls-esni/issues/380 - Replace config_id with a server-chosen key_id https://github.com/tlswg/draft-ietf-tls-esni/issues/375 * tlswg/tls13-spec (+2/-4/💬21) 2 issues created: - Double check issues filed in ekr/ repo. (by ekr) https://github.com/tlswg/tls13-spec/issues/1216 - Implication of Recommended/Not Recommended (by ekr) https://github.com/tlswg/tls13-spec/issues/1214 4 issues received 21 new comments: - #1214 Implication of Recommended/Not Recommended (10 by davidben, ekr, martinthomson, richsalz) https://github.com/tlswg/tls13-spec/issues/1214 - #1212 general alert (7 by davidben, richsalz, tomato42) https://github.com/tlswg/tls13-spec/issues/1212 - #1209 "client authentication" -> "certificate-based client authentication" (1 by ekr) https://github.com/tlswg/tls13-spec/issues/1209 - #1208 Contradition around user_cancelled (3 by davidben, ekr) https://github.com/tlswg/tls13-spec/issues/1208 4 issues closed: - "client authentication" -> "certificate-based client authentication" https://github.com/tlswg/tls13-spec/issues/1209 - Even shorter secret names? https://github.com/tlswg/tls13-spec/issues/1200 - Handle remaining TLS 1.2 names https://github.com/tlswg/tls13-spec/issues/1203 - Discuss tracking implications of session resumption https://github.com/tlswg/tls13-spec/issues/1201 * tlswg/dtls-conn-id (+0/-0/💬4) 1 issues received 4 new comments: - #80 Section 9 comment from Ben (4 by boaks, jsalowey, thomas-fossati) https://github.com/tlswg/dtls-conn-id/issues/80 Pull requests - * tlswg/draft-ietf-tls-esni (+4/-2/💬2) 4 pull requests submitted: - Add note about denial-of-service vulnerability (by cjpatton) https://github.com/tlswg/draft-ietf-tls-esni/pull/385 - Clarify privacy risk pertaining to resumption. (by cbartle891) https://github.com/tlswg/draft-ietf-tls-esni/pull/383 - Clarify "don't stick out" considerations (by cjpatton) https://github.com/tlswg/draft-ietf-tls-esni/pull/382 - Truncate the config_id to a single byte. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/381 2 pull requests received 2 new comments: - #385 Add note about denial-of-service vulnerability (1 by cjpatton) https://github.com/tlswg/draft-ietf-tls-esni/pull/385 - #313 Replace record-level padding with handshake-level padding (1 by cjpatton) https://github.com/tlswg/draft-ietf-tls-esni/pull/313 2 pull requests merged: - Clarify privacy risk pertaining to resumption. https://github.com/tlswg/draft-ietf-tls-esni/pull/383 - Move to a key identity in lieu of the config identifier hash. https://github.com/tlswg/draft-ietf-tls-esni/pull/376 * tlswg/tls13-spec (+2/-6/💬1) 2 pull requests submitted: - minor editorial spelling (by emanjon) https://github.com/tlswg/tls13-spec/pull/1215 - Changelog for -01 (by ekr) https://github.com/tlswg/tls13-spec/pull/1213 1 pull requests received 1 new comments: - #1215 minor editorial spelling (1 by ekr) https://github.com/tlswg/tls13-spec/pull/1215 6 pull requests merged: - Changelog for -01 https://github.com/tlswg/tls13-spec/pull/1213 - Shorten some unnecessarily long names. https://github.com/tlswg/tls13-spec/pull/1202 - Align TLS 1.2 terminology with this document https://github.com/tlswg/tls13-spec/pull/1204 - Security Property - Protection of endpoint identities https://github.com/tlswg/tls13-spec/pull/1210 - Discuss tracking implications of session resumption. https://github.com/tlswg/tls13-spec/pull/1205 - Editorial: "Client Authentication" -> "Certificate-Based Client Authentication" https://github.com/tlswg/tls13-spec/pull/1211 * tlswg/dtls-conn-id (+0/-0/💬2) 2 pull requests received 2 new comments: - #86 Add Achim Kraus to authors. (1 by jsalowey) https://github.com/tlswg/dtls-conn-id/pull/86 - #81 Corrected statement about multi-homing and CID changes (1
