Re: [TLS] Re-chartering TLS
LGTM On Thu, Jan 16, 2020 at 7:32 PM Christopher Wood wrote: > Hi folks, > > As discussed in Singapore, it's time to re-charter the working group to > reflect ongoing (e.g., Exported Authenticators and Encrypted SNI/CH) and > future work (e.g., cTLS). For reference, the current charter is available > here: > >https://datatracker.ietf.org/doc/charter-ietf-tls/ > > A draft of the new charter is below, and also available on GitHub [1]. > Please have a look and and send comments, either here on the mailing list > or in the GitHub repo, by 2359 UTC on 30 January 2020. Any and all feedback > is welcome! We would like to complete this in advance of IETF 107 so we can > move forward with items such as cTLS. > > ~~~ > The TLS (Transport Layer Security) working group was established in 1996 > to standardize a 'transport layer' security protocol. The basis for the > work was SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group > has completed a series of specifications that describe the TLS protocol > v1.0 [RFC2246], v1.1 [RFC4346], v1.2 [RFC5346], and v1.3 [RFC8446], and > DTLS (Datagram TLS) v1.0 [RFC4347], v1.2 [RFC6347], and v1.3 > [draft-ietf-tls-dtls13], as well as extensions to the protocols and > ciphersuites. > > The working group aims to achieve three goals. First, improve the > applicability and suitability of the TLS family of protocols for use in > emerging protocols and use cases. This includes extensions or changes that > help protocols better use TLS as an authenticated key exchange protocol, or > extensions that help protocols better leverage TLS security properties, > such as Exported Authenticators. Extensions that focus specifically on > protocol extensibility are also in scope. This goal also includes protocol > changes that reduce the size of TLS without affecting security. Extensions > that help reduce TLS handshake size meet this criteria. > > The second working group goal is to improve security, privacy, and > deployability. This includes, for example, Delegated Credentials, Encrypted > SNI, and GREASE. Security and privacy goals will place emphasis on the > following: > > - Encrypt the ClientHello SNI (Server Name Indication) and other > application-sensitive extensions, such as ALPN (Application-Layer Protocol > Negotiation). > - Identify and mitigate other (long-term) user tracking or fingerprinting > vectors enabled by TLS deployments and implementations. > > The third goal is to maintain current and previous version of the (D)TLS > protocol as well as to specify general best practices for use of (D)TLS, > extensions to (D)TLS, and cipher suites. This includes recommendations as > to when a particular version should be deprecated. Changes or additions to > older versions of (D)TLS whether via extensions or ciphersuites are > discouraged and require significant justification to be taken on as work > items. > > With these goals in mind, the working group will also place a priority in > minimizing gratuitous changes to (D)TLS. > ~~~ > > Best, > Chris, on behalf of the chairs > > [1] https://github.com/tlswg/wg-materials/blob/master/charter/charter.md > > ___ > 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
[TLS] External PSK design team
At IETF 106, we discussed forming a design team to focus on external PSK management and usage for TLS. The goal of this team would be to produce a document that discusses considerations for using external PSKs, privacy concerns (and possible mitigations) for stable identities, and more developed mitigations for deployment problems such as Selfie. If you have an interest in participating on this design team, please reply to this message and state so by 2359 UTC 31 January 2020. Cheers, Joe and Sean ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] External PSK design team
On Mon, Jan 20, 2020 at 8:01 PM Sean Turner wrote: > At IETF 106, we discussed forming a design team to focus on external PSK > management and usage for TLS. The goal of this team would be to produce a > document that discusses considerations for using external PSKs, privacy > concerns (and possible mitigations) for stable identities, and more > developed mitigations for deployment problems such as Selfie. If you have > an interest in participating on this design team, please reply to this > message and state so by 2359 UTC 31 January 2020. > Today is a holiday in the US, so you might not hear back until folks in the US catch up tomorrow. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Thu, Nov 21, 2019, at 14:19, David Schinazi wrote: > Regarding Viktor's suggestion, I personally believe it would increase the > complexity of the proposal, and I don't see use-cases compelling enough > to warrant that complexity. I would rather keep this proposal as simple as > possible. I see that I didn't respond to this. I support David's view. Even the suggestion that clients that resume only request one assumes that clients only want one. The client probably knows better than we do. I would rather say nothing about the number and keep it simple. 0 means 0, 1 means 1, N means N. FWIW, the cost of oversupply is often marginal, depending on circumstances. In a client-speaks-first protocol with no client certificate, the server can occupy the first round trip with tickets and generally gain a performance advantage (as sending more will increase the congestion window in most cases). Otherwise, there are usually quiescent periods that can be exploited for sending tickets. And tickets are small, and cheap to generate. With one exception: if you are relying on client authentication and packing that into tickets, I'm sorry. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] External PSK design team
Interested, as it happens - this is something I've been working on at Amazon. On Mon, Jan 20, 2020 at 8:01 PM Sean Turner wrote: > > At IETF 106, we discussed forming a design team to focus on external PSK > management and usage for TLS. The goal of this team would be to produce a > document that discusses considerations for using external PSKs, privacy > concerns (and possible mitigations) for stable identities, and more developed > mitigations for deployment problems such as Selfie. If you have an interest > in participating on this design team, please reply to this message and state > so by 2359 UTC 31 January 2020. > > Cheers, > > Joe and Sean > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Colm ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Tue, Jan 21, 2020 at 04:03:46PM +1100, Martin Thomson wrote: > On Thu, Nov 21, 2019, at 14:19, David Schinazi wrote: > > Regarding Viktor's suggestion, I personally believe it would increase the > > complexity of the proposal, and I don't see use-cases compelling enough > > to warrant that complexity. I would rather keep this proposal as simple as > > possible. > > I see that I didn't respond to this. I support David's view. > > Even the suggestion that clients that resume only request one assumes > that clients only want one. The client probably knows better than we > do. I would rather say nothing about the number and keep it simple. 0 > means 0, 1 means 1, N means N. The proposal has since been simplified. With 1 meaning 1, 2 meaning 2, The only change is that 0 and 255 become special, with 255 meaning definitely no tickets, and 0 meaning tickets only if the server sees a need a replace the presented ticket. Otherwise, the client has no way to request refresh only if needed, and must ask for 1 just in case. Unnecessary tickets are a waste server and client resources and bandwidth, and make external caches "hot" on clients that are perfectly fine with a slowly changing series of multi-use tickets. > FWIW, the cost of oversupply is often marginal, depending on > circumstances. In a client-speaks-first protocol with no client > certificate, the server can occupy the first round trip with tickets > and generally gain a performance advantage (as sending more will > increase the congestion window in most cases). This is useless for clients with just a single mult-use slot in their ticket cache. Not everything is a web browser. > Otherwise, there are usually quiescent periods that can be exploited > for sending tickets. And tickets are small, and cheap to generate. > With one exception: if you are relying on client authentication and > packing that into tickets, I'm sorry. There's no need to exclude valid use-cases. The refined proposal is rather non-invasive, and handles this case cost-effectively on clients that re-use tickets (and don't use early-data, ...). -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
