Re: [TLS] Feedback on draft-ietf-tls-tlsflags
On Thursday, 30 January 2020 21:08:39 CET, Stephen Farrell wrote: On 30/01/2020 17:57, Yoav Nir wrote: Hi folks. In case you’re not following GitHub, there was an issue with a brief discussion ([1]) and a resulting pull request ([2]). If there are no objections by late next week, I will merge the PR. Allowing 2040 flags seems a bit mad and a possible foot-gun - with a specification required rule that could end up worse than the ciphersuites registry! Given it's possible to define a tls_flags2 extension if this one runs out, I'd argue to constrain this to a much smaller number of flags - 63 should be plenty I'd say. That said, it's not that huge a deal since I have a hard time seeing implementers even trying to code for 2040 flags and specification required is the same rule as for extensions. well, if the specification says that it can include 2040 flags, an implementation must be able to process such an extension if the idea of this extension is to reduce the size of ClientHello (the utility of which I find questionable), then I don't see a situation where we will really need to send old and new extensions at the same time as likely – I expect that if we do allow 2040 flags, the extension in 10 or 20 years will commonly include just few set bits and plenty of zeros – wasting bandwidth again -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Feedback on draft-ietf-tls-tlsflags
> On 30 Jan 2020, at 22:08, Stephen Farrell wrote: > > > > On 30/01/2020 17:57, Yoav Nir wrote: >> Hi folks. >> >> In case you’re not following GitHub, there was an issue with a brief >> discussion ([1]) and a resulting pull request ([2]). >> >> If there are no objections by late next week, I will merge the PR. > > Allowing 2040 flags seems a bit mad and a possible > foot-gun - with a specification required rule that > could end up worse than the ciphersuites registry! > > Given it's possible to define a tls_flags2 extension > if this one runs out, I'd argue to constrain this to a > much smaller number of flags - 63 should be plenty > I'd say. > > That said, it's not that huge a deal since I have > a hard time seeing implementers even trying to code > for 2040 flags and specification required is the > same rule as for extensions. > > Cheers, > S. The format allows 2040 bits. I think we should never define that many bits. I think we should never define even 60 bits. But I also think it should be left up to the TLS chairs and the IANA experts to serve as gatekeepers rather than tying their hands in the specification. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Feedback on draft-ietf-tls-tlsflags
> On 31 Jan 2020, at 14:26, Hubert Kario wrote: > > On Thursday, 30 January 2020 21:08:39 CET, Stephen Farrell wrote: >> >> On 30/01/2020 17:57, Yoav Nir wrote: >>> Hi folks. >>> In case you’re not following GitHub, there was an issue with a brief >>> discussion ([1]) and a resulting pull request ([2]). >>> If there are no objections by late next week, I will merge the PR. >> >> Allowing 2040 flags seems a bit mad and a possible >> foot-gun - with a specification required rule that >> could end up worse than the ciphersuites registry! >> >> Given it's possible to define a tls_flags2 extension >> if this one runs out, I'd argue to constrain this to a >> much smaller number of flags - 63 should be plenty >> I'd say. >> >> That said, it's not that huge a deal since I have >> a hard time seeing implementers even trying to code >> for 2040 flags and specification required is the >> same rule as for extensions. > > well, if the specification says that it can include 2040 flags, an > implementation > must be able to process such an extension > > if the idea of this extension is to reduce the size of ClientHello (the > utility > of which I find questionable), then I don't see a situation where we will > really > need to send old and new extensions at the same time as likely – I expect that > if we do allow 2040 flags, the extension in 10 or 20 years will commonly > include > just few set bits and plenty of zeros – wasting bandwidth again An implementation need only support up to the last bit that is meaningful to it. If the last feature it supports is number 30, there’s no need to read any of the octets beyond the fourth I think that we can help the situation by partitioning the space as follows: - First octet is for standards-track documents coming out of TLS where the draft specifically requests such assignment. Like if we ever need a renegotiation_info again. - Octets 2-4 are for other standards-track documents. - Octets 5-7 are for experimental drafts. They don’t get re-assigned if they later become standards track - Octets 8 are reserved-private - Octets beyond that are in case we need more. With some luck and some care, most ClientHellos will need no more than the first 4 bytes. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Feedback on draft-ietf-tls-tlsflags
On Fri, Jan 31, 2020 at 04:00:39PM +0200, Yoav Nir wrote: > > > > On 30 Jan 2020, at 22:08, Stephen Farrell wrote: > > > > > > > > On 30/01/2020 17:57, Yoav Nir wrote: > >> Hi folks. > >> > >> In case you’re not following GitHub, there was an issue with a brief > >> discussion ([1]) and a resulting pull request ([2]). > >> > >> If there are no objections by late next week, I will merge the PR. > > > > Allowing 2040 flags seems a bit mad and a possible > > foot-gun - with a specification required rule that > > could end up worse than the ciphersuites registry! Well, TLS allows tens of thoursands of extensions, and the extension registry does not look even nearly as bad as ciphersuite registry. This has multiple possible reasons: - Much harder to specify extensions. - Less "vanity" stuff with extensions. - No bad combinatorics (ciphersuites were horrible combinatorics-wise before being reworked in TLS 1.3). > > Given it's possible to define a tls_flags2 extension > > if this one runs out, I'd argue to constrain this to a > > much smaller number of flags - 63 should be plenty > > I'd say. One would not want any high-numbered flags, so splitting to multiple extensions if there would be many flags would likely be benefical size-wise. One could support 64 flags with size bound of 12 bytes (8 bytes plus 4 byte extension overhead). Note that 64 is more than number of all TLS extensions ever registered (let alone number of flaglike TLS extensions). > > That said, it's not that huge a deal since I have > > a hard time seeing implementers even trying to code > > for 2040 flags and specification required is the > > same rule as for extensions. Note that it would not be much harder to make an extension than a flag. It would pretty much just specifying the extension as blank. One needs to specify the semantics anyway. > The format allows 2040 bits. I think we should never define that many > bits. I think we should never define even 60 bits. But I also think > it should be left up to the TLS chairs and the IANA experts to serve > as gatekeepers rather than tying their hands in the specification. Note that the length field is completely redundant and could be removed, saving 1 byte. And I think that even defining 16 flags (to exceed 6 bytes) will take a while (that is more than all flag-type extensions that exist to date). And probably there should not be any reserved entries, just all "specification required". Or maybe some low number entries (0-7?) for "standards action" (mostly to be used for any possible security fix extensions)? -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Feedback on draft-ietf-tls-tlsflags
test only -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] PSK design team email
Thanks to everyone who volunteered to participate in the external PSK design team [0]. We will send off a kickoff email to the group soon. Note that we do not expect the design team to finish their work by IETF 107 given the short amount of time remaining before that meeting. Thanks, Sean [0] https://ietf.org/about/groups/iesg/statements/design-teams/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Re-chartering TLS
Thanks to everyone who provided feedback on the draft charter! It’s all been incorporated in the version on GitHub [1]. We’ll work with Ben in moving this to the next step. Thanks, Chris, on behalf of the chairs [1] https://github.com/tlswg/wg-materials/blob/master/charter/charter.md On Mon, Jan 20, 2020, at 1:55 PM, Eric Rescorla wrote: > 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
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
First off, thanks for the lively discussion on ticket reuse! I think it's a valid use case and something that should continue to be discussed. However, for the purposes of the WGLC for this draft, draft-ietf-tls-ticketrequests, it may be best to separate the conversation. It seems that the negotiation of ticket reuse would be best served by another document that could be adopted by the WG. The ticket request document, as it was adopted, was specifically a mechanism to request multiple tickets so as to *avoid* ticket reuse. This is stated several times in the use cases (section 2) and security considerations (section 5). While this does not preclude a future extension that negotiates ticket reuse, I believe, as an author, that enabling ticket reuse is out of scope of this particular document. Best, Tommy > On Jan 23, 2020, at 1:01 PM, Viktor Dukhovni wrote: > > On Thu, Jan 23, 2020 at 01:32:51PM -0600, Nico Williams wrote: > >> On Thu, Jan 23, 2020 at 09:43:21AM -0800, Watson Ladd wrote: >>> Sending a new ticket doesn't force clients to store it. >> >> Sure, but if the old ticket will not be accepted again then the client >> will incur a full handshake later. The client doesn't know if the old >> ticket will or will not be accepted again. Extending the protocol to >> have the server signal that bit will require new OpenSSL extensions, >> which is why that is not a sufficiently good response to the Postfix >> issue. > > Indeed, not storing the ticket breaks resumption. So I always store the > ticket (actually what OpenSSL hands me is a serializable opaque > SSL_SESSION). For example, when the server allows reuse, but has a > shorter maximum ticket lifetime, its "as needed" new ticket needs to be > stored, in order to replace a stale cached session and start using the > fresh one. > > Regardless, I also believe that not applications need or want the > marginal privacy offered by single-use tickets (none for clients > with stable dedicated IP addresses) and it should be possible > in such cases (at effectively zero cost as proposed) to negotiate > reuse in a way that allows servers to handle both types of client. > > This would allow Postfix to vend single-use tickets to clients > that request that (e.g. MUAs). Right now the code is statically > optimized for the MTA-to-MTA use-case. > > So making reuse *negotiable* would in fact enhance privacy for MUAs on > ephemeral IPs sending sufficiently frequent email (from behind a NAT or > otherwise shared or changing address) to a sufficiently popular > submission server that it is not trivial to link resumed TLS sessions to > a given client. > > -- >Viktor. > > ___ > 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 draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 09:06:12AM -0800, Tommy Pauly wrote: > However, for the purposes of the WGLC for this draft, > draft-ietf-tls-ticketrequests, it may be best to separate the > conversation. It seems that the negotiation of ticket reuse would be > best served by another document that could be adopted by the WG. The > ticket request document, as it was adopted, was specifically a > mechanism to request multiple tickets so as to *avoid* ticket reuse. Yes, but the issues DO NOT decouple. It is a mechanism to communicate the client's ticket requirements to the server. Many clients will want multiple tickets unconditionally, some will want none, or only one as the presented one becomes no longer valid. The use-case is that the Postfix SMTP server currently always vends replacement tickets ONLY when expiring. I'd like to be able to distinguish between clients that always want fresh tickcets (MUAs) and clients that don't (MTAs). This will also reduce ticket reuse. > This is stated several times in the use cases (section 2) and security > considerations (section 5). While this does not preclude a future > extension that negotiates ticket reuse, I believe, as an author, that > enabling ticket reuse is out of scope of this particular document. The two extensions will be in conflict. There's a trivial solution within the existing extension. One code of 255 fully addresses the issue, with no additional document required. Proliferation of conflicting documents does not help implementors. Let's address the issue before us in a single document. Reuse is not a separate issue, both are just ticket quantity negotiation. -- VIktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PSK design team email
That sounds great. Note that the linked IESG statement says: - the membership of the design team must also be public and posted to the mailing list. - any design team that lasts for more than a few months should make regular public reports on what they are doing. It sounds like this design team will last more than a few months, so a public report on their activity might be expected after IETF 107 (a few months from now...). thanks, Rob On Fri, Jan 31, 2020 at 8:37 AM Sean Turner wrote: > Thanks to everyone who volunteered to participate in the external PSK > design team [0]. We will send off a kickoff email to the group soon. Note > that we do not expect the design team to finish their work by IETF 107 > given the short amount of time remaining before that meeting. > > Thanks, > Sean > > [0] https://ietf.org/about/groups/iesg/statements/design-teams/ > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 09:06:12AM -0800, Tommy Pauly wrote: > First off, thanks for the lively discussion on ticket reuse! I think > it's a valid use case and something that should continue to be > discussed. > > However, for the purposes of the WGLC for this draft, > draft-ietf-tls-ticketrequests, it may be best to separate the > conversation. It seems that the negotiation of ticket reuse would be > best served by another document that could be adopted by the WG. The Viktor's comment came before the end of WGLC, so the WG needs to consider his comments, and needs to reach consensus. Considering the fact that cosensus has not yet _obviously_ been reached (there have been positive and negative responses), the WG's chairs may need to make a call for consensus (or maybe the chairs think consensus is obvious?). Consider this my encouragement to the chairs that they make a call for consensus. > ticket request document, as it was adopted, was specifically a > mechanism to request multiple tickets so as to *avoid* ticket reuse. TLS 1.3 already does that. The adoption call is nowhere near as specific -- in fact, it says nothing about purpose of the extension. The TLS WG charter doesn't mention it. The abstract of this I-D says, among other things: This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste, while ^ simultaneously priming clients for future connection attempts. That number could be zero, and indeed, that's allowed. "Zero unless you won't allow me to reuse this one" seems clearly in-scope to me. That you have no need for it, doesn't make it out of scope or a bad idea. Moreover, I posted an explanation of why this extension will cause Postfix trouble. That deserves a substantive response (and IETF process may even demand it). Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
+1 to what Nico says. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 3:56 PM Nico Williams wrote: > On Fri, Jan 31, 2020 at 09:06:12AM -0800, Tommy Pauly wrote: > > First off, thanks for the lively discussion on ticket reuse! I think > > it's a valid use case and something that should continue to be > > discussed. > > > > However, for the purposes of the WGLC for this draft, > > draft-ietf-tls-ticketrequests, it may be best to separate the > > conversation. It seems that the negotiation of ticket reuse would be > > best served by another document that could be adopted by the WG. The > > Viktor's comment came before the end of WGLC, so the WG needs to > consider his comments, Yes. > and needs to reach consensus. > No. This draft should move forward. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 04:58:07PM -0800, Rob Sayre wrote: > On Fri, Jan 31, 2020 at 3:56 PM Nico Williams wrote: > > Viktor's comment came before the end of WGLC, so the WG needs to > > consider his comments, > > Yes. > > > and needs to reach consensus. > > No. This draft should move forward. WGLCs are not about finding and discussing spelling errors. This is not how the Standards-Track RFC publication process works. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 5:11 PM Nico Williams wrote: > On Fri, Jan 31, 2020 at 04:58:07PM -0800, Rob Sayre wrote: > > On Fri, Jan 31, 2020 at 3:56 PM Nico Williams > wrote: > > > Viktor's comment came before the end of WGLC, so the WG needs to > > > consider his comments, > > > > Yes. > > > > > and needs to reach consensus. > > > > No. This draft should move forward. > > WGLCs are not about finding and discussing spelling errors. This is not > how the Standards-Track RFC publication process works. > If the scope of a document can be continually expanded during last call, it can be indefinitely postponed. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 05:15:40PM -0800, Rob Sayre wrote: > If the scope of a document can be continually expanded during last call, it > can be indefinitely postponed. There is no attempt to postpone, and the WGLC has finished. No new issues will be raised. But the ones that were raised _will_ be addressed. Being left on the rough side of consensus happens; having substantive issues raised in a timely manner ignored must not. The IETF is not a rubber-stamp SDO. We have a process. We don't just pay it lip service. WGLC is not going through the motions. The prescribed process will be followed. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
> On Jan 31, 2020, at 8:15 PM, Rob Sayre wrote: > > If the scope of a document can be continually expanded during last call, it > can be indefinitely postponed. I'm not proposing a change of scope. The document specifies how a client and server negotiate the number of tickets the server should send. This remains the case. The -04 document leaves out a relevant scenario where the client does want tickets to be refreshed (so not unconditionally zero), but does not want gratuitous tickets (new one each time). The scope of the document per the abstract includes the following: This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste, while simultaneously priming clients for future connection attempts My proposal falls squarely in the "in order to reduce ticket waste" category. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 5:24 PM Viktor Dukhovni wrote: > > On Jan 31, 2020, at 8:15 PM, Rob Sayre wrote: > > > > If the scope of a document can be continually expanded during last call, > it can be indefinitely postponed. > > I'm not proposing a change of scope. > The -04 document leaves out a relevant scenario... > That sounds like a change of scope, but reasonable people can disagree. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 05:43:36PM -0800, Rob Sayre wrote: > On Fri, Jan 31, 2020 at 5:24 PM Viktor Dukhovni > wrote: > > > > On Jan 31, 2020, at 8:15 PM, Rob Sayre wrote: > > > > > > If the scope of a document can be continually expanded during last call, > > it can be indefinitely postponed. > > > > I'm not proposing a change of scope. > > > > > > The -04 document leaves out a relevant scenario... > > > > That sounds like a change of scope, but reasonable people can disagree. The scope was never sufficiently well defined to begin with. I went through the adoption thread and the WG charter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 07:47:57PM -0600, Nico Williams wrote: > On Fri, Jan 31, 2020 at 05:43:36PM -0800, Rob Sayre wrote: > > On Fri, Jan 31, 2020 at 5:24 PM Viktor Dukhovni > > wrote: > > > > > > On Jan 31, 2020, at 8:15 PM, Rob Sayre wrote: > > > > > > > > If the scope of a document can be continually expanded during last call, > > > it can be indefinitely postponed. > > > > > > I'm not proposing a change of scope. > > > > > > > > > > > The -04 document leaves out a relevant scenario... > > > > > > > That sounds like a change of scope, but reasonable people can disagree. > > The scope was never sufficiently well defined to begin with. I went > through the adoption thread and the WG charter. Oh, and I'm not conceding that the proposed change would be a scope change even if the scope had been sufficiently well defined. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 8:16 PM Rob Sayre wrote: > On Fri, Jan 31, 2020 at 5:11 PM Nico Williams > wrote: > >> On Fri, Jan 31, 2020 at 04:58:07PM -0800, Rob Sayre wrote: >> > On Fri, Jan 31, 2020 at 3:56 PM Nico Williams >> wrote: >> > > Viktor's comment came before the end of WGLC, so the WG needs to >> > > consider his comments, >> > >> > Yes. >> > >> > > and needs to reach consensus. >> > >> > No. This draft should move forward. >> >> WGLCs are not about finding and discussing spelling errors. This is not >> how the Standards-Track RFC publication process works. >> > > If the scope of a document can be continually expanded during last call, > it can be indefinitely postponed. > > It is unclear to me how this applies here. Could you be a bit more explicit and state what, in your opinion, is continually expanding ? > thanks, > Rob > > ___ > 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 draft-ietf-tls-ticketrequests
Hi Viktor, > On Jan 31, 2020, at 5:24 PM, Viktor Dukhovni wrote: > >> On Jan 31, 2020, at 8:15 PM, Rob Sayre wrote: >> >> If the scope of a document can be continually expanded during last call, it >> can be indefinitely postponed. > > I'm not proposing a change of scope. The document specifies how a client > and server negotiate the number of tickets the server should send. This > remains the case. The -04 document leaves out a relevant scenario where > the client does want tickets to be refreshed (so not unconditionally zero), > but does not want gratuitous tickets (new one each time). > > The scope of the document per the abstract includes the following: > > This extension aims to provide a means for > servers to determine the number of tickets to generate in order to > reduce ticket waste, while simultaneously priming clients for future > connection attempts > > My proposal falls squarely in the "in order to reduce ticket waste" category. The document also is focused on use cases that are all about "avoid[ing] ticket re-use". The security considerations state that "Ticket re-use is a security and privacy concern". While there are some use cases in which ticket re-use allows the reduction of ticket waste, we cannot state that every possible approach to reduce ticket waste is in scope for this particular document. Rather, this document defines its scope as simply: "This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections." Enabling ticket reuse is not part of that scope. Beyond discussing scope creep, I think an even bigger reason to decouple the idea of ticket requests from explicit ticket re-use is the notion of working group consensus. I think the WG has clearly expressed consensus on the fact that ticket requests are a useful and non-harmful extension. Indeed, the proposals to add ticket reuse logic to ticket requests that you want relies on such an extension. However, the group certainly does not seem to have consensus on the idea that there should be an extension to allow ticket reuse. As an author, I don't know if I'd support that. Thus, the working group can progress with the tightly-scoped document that it has consensus on, and leave other use cases to future documents. Thanks, Tommy > > -- > Viktor. > > ___ > 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 draft-ietf-tls-ticketrequests
Hi Nico, As a point on the process, I don't think anyone is proposing rubber-stamping. We are instead only suggesting that a set of work that has consensus does not need to be held up by adding new work that does not have consensus. The outcome of points raised during a WGLC does not need to be a change in the document, if the group does not have consensus that the suggested change is correct. Particularly, as in this case, a comment during WGLC to add new functionality that is not part of addressing the intended scope of a working group deliverable does not need to be added before progressing. I think this is a case in which we have consensus on the basic ticket requests, but adding ticket reuse is (based on the way this thread has not converged) is in the rough. Thanks, Tommy > On Jan 31, 2020, at 5:23 PM, Nico Williams wrote: > > On Fri, Jan 31, 2020 at 05:15:40PM -0800, Rob Sayre wrote: >> If the scope of a document can be continually expanded during last call, it >> can be indefinitely postponed. > > There is no attempt to postpone, and the WGLC has finished. No new > issues will be raised. But the ones that were raised _will_ be > addressed. Being left on the rough side of consensus happens; having > substantive issues raised in a timely manner ignored must not. > > The IETF is not a rubber-stamp SDO. We have a process. We don't just > pay it lip service. WGLC is not going through the motions. The > prescribed process will be followed. > > Nico > -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
> On Jan 31, 2020, at 8:53 PM, Tommy Pauly > wrote: > > Thus, the working group can progress with the tightly-scoped document that it > has consensus on, and leave other use cases to future documents. Such a deferral may be desirable and viable in cases where the features are sufficiently orthogonal. But here the extension specifies the number of requested tickets, and so any separate document would have to change the semantics of this extension in order to get conditional issuance of tickets. It makes no sense to split the negotiation of the ticket number over multiple documents. The added use-case is effectively *free* to ignore by implementations that never want reuse, just treat zero as 1, and be done. If this were a major burdensome feature, I'd be sympathetic to your desire to carve it out to a separate discussion. But here, I'm pretty consensus will be reached soon after we stop focusing on the legitimacy or timing of the proposal and focus on its substance in a final wrap-up consensus call. I may end up in the rough, but let's at least see where the chips fall. The security considerations can continue to discourage reuse where traffic analysis is a concern. It is NOT a concern in MTA-to-MTA traffic. If my proposal moves forward, I'll gladly contribute some text to the security considerations discouraging wanton application of ticket reuse. It should be enabled only where appropriate. Note that I'd like to use this extension to conditionally enable non-reuse where presently re-use is unconditional. Otherwise, Postfix will just always go with reuse. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 05:59:23PM -0800, Tommy Pauly wrote: > As a point on the process, I don't think anyone is proposing > rubber-stamping. We are instead only suggesting that a set of work > that has consensus does not need to be held up by adding new work that > does not have consensus. A substantive issue was raised. Until that is disposed of through normal consensus-finding mechanisms, there is no consensus for the I-D to progress. That's how the process works. > The outcome of points raised during a WGLC does not need to be a > change in the document, if the group does not have consensus that the Correct. But first that consensus needs to be reached. > suggested change is correct. Particularly, as in this case, a comment > during WGLC to add new functionality that is not part of addressing > [...] That's not how the process works. Of course a substantive issue raised at WGLC or IETF LC time (or IESG review time) can require new functionality to be addressed properly! There is no rule that no functionality may be added as a result of a WGLC/IETF LC comment. Or that comments that would require new functionality can be rejected by the I-D's authors alone. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 6:07 PM Nico Williams wrote: > > A substantive issue was raised. Until that is disposed of through > normal consensus-finding mechanisms, there is no consensus for the I-D > to progress. That's how the process works. > Explain your reasoning. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
Hiya, I have no particular position about this draft but am curious about 2 things: #1 I don't get why it's not possible for postfix to determine the best way to manage tickets based on the destination port to which the ClientHello is sent. I totally get why that won't solve 100% of cases, but it would surely solve a huge percentage? Apologies if an answer was already posted as part of this v. long thread. #2 I don't get why Viktor's request for special handling for value 255 is a real problem for anyone. We have another thread today envisaging 2040 extensions flags, so I really have a hard time seeing what here justifies rejecting Viktor's argument. FWIW, this thread has not provided me with an obvious answer to #2 other than "not- invented-here." I'm not sure that declaring things in the rough where the only identifiable issue is NIH is the overall best outcome, longer term. Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 9:14 PM Stephen Farrell wrote: > > Hiya, > > I have no particular position about this draft but > am curious about 2 things: > > #1 I don't get why it's not possible for postfix to > determine the best way to manage tickets based on the > destination port to which the ClientHello is sent. I > totally get why that won't solve 100% of cases, but it > would surely solve a huge percentage? Apologies if an > answer was already posted as part of this v. long > thread. > > #2 I don't get why Viktor's request for special handling > for value 255 is a real problem for anyone. We have > another thread today envisaging 2040 extensions flags, > so I really have a hard time seeing what here justifies > rejecting Viktor's argument. FWIW, this thread has not > provided me with an obvious answer to #2 other than "not- > invented-here." I'm not sure that declaring things in the > rough where the only identifiable issue is NIH is the > overall best outcome, longer term. > + 1 I have not seen any technical answer either for not considering this mechanism. > > 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 draft-ietf-tls-ticketrequests
* If the scope of a document can be continually expanded during last call, it can be indefinitely postponed. No, the WG can get consensus on not expanding scope. It’s not great that this came up with WGLC, but several folks in the WG now recognize that this is an important use-case and feel it’s in-scope. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 6:21 PM Salz, Rich wrote: > > >- If the scope of a document can be continually expanded during last >call, it can be indefinitely postponed. > > > > No, the WG can get consensus on not expanding scope. > That's true, but there's no need to stop if the expanded scope doesn't have consensus. > It’s not great that this came up with WGLC, but several folks in the WG > now recognize that this is an important use-case and feel it’s in-scope. > Not sure "several" is the correct term. There are some mailing list messages about the topic. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
>Not sure "several" is the correct term. There are some mailing list messages >about the topic. A few people who are heavily involved in this WG have agreed this is an issue, and a few people aren’t. Shrug. As Nico said, time for a consensus call or more likely a discussion in Vancouver. I think I’m done adding useful content to this thread. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 6:30 PM Salz, Rich wrote: > *>*Not sure "several" is the correct term. There are some mailing list > messages about the topic. > > > > A few people who are heavily involved in this WG have agreed this is an > issue, and a few people aren’t. Shrug. As Nico said, time for a consensus > call or more likely a discussion in Vancouver. > Sounds important. > I think I’m done adding useful content to this thread. > Agree. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Fri, Jan 31, 2020 at 6:07 PM Nico Williams mailto:n...@cryptonector.com>> wrote: A substantive issue was raised. Until that is disposed of through normal consensus-finding mechanisms, there is no consensus for the I-D to progress. That's how the process works. * Explain your reasoning. Sec 7 of RFC 2418 (IETF Working Group Guidelines and Procedures): A working group Last-Call serves the same purpose within a working group that an IESG Last-Call does in the broader IETF community. Sec 14 of RFC 2026 (The Internet Standards Process -- Revision 3): “Last-Call - A public comment period used to gage the level of consensus about the reasonableness of a proposed standards action.” ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On Sat, Feb 01, 2020 at 02:13:37AM +, Stephen Farrell wrote: > #1 I don't get why it's not possible for Postfix to determine the best >way to manage tickets based on the destination port to which the >ClientHello is sent. I totally get why that won't solve 100% of >cases, but it would surely solve a huge percentage? Apologies if an >answer was already posted as part of this v. long thread. The Postfix SMTP server does not actually create the listener socket, and may not even be getting the traffic directly from the network (e.g. haproxy, postscreen, DNAT, ...). Such a heuristic would require action from the server administrator to configure appropriate policy for each non-default instance of an SMTP service, and would then still yield only approximately correct results. SMTP relays aren't always on port 25, and services that are dedicated MSAs are sometimes in fact on port 25. Also, though I wish other MTAs that support TLS resumption would also reuse tickets, avoiding waste. I don't know what TLS stacks they use, and whether they need or don't need fresh tickets. And coversely not every server Postfix connects to is also Postfix, and those may have a different default behaviour. So I'm looking for a mechanism (absolutely trivial per #2 below) to allow the client to signal to the server its ticket-use preference so that the server can vend the right number of tickets (which is the scope of this extension). > #2 I don't get why Viktor's request for special handling for value 255 >is a real problem for anyone. We have another thread today >envisaging 2040 extensions flags, so I really have a hard time >seeing what here justifies rejecting Viktor's argument. FWIW, this >thread has not provided me with an obvious answer to #2 other than >"not- invented-here." I'm not sure that declaring things in the >rough where the only identifiable issue is NIH is the overall best >outcome, longer term. I am also puzzled by the reticence to make the trivial change that makes the mechanism more expressive at negligible cost, and move on. That too advances the draft. I want to see this draft move forward, that's why I am bothering to try and make it cover the missing piece of the puzzle. There is NO obligation on either party to enable reuse even if the client sends the "as necessary" sentinel (0). The server can just vend 1 new ticket in that case, and the client would need to assume the previous one invalid and use the new one for the next connection. The proposal does not change the security posture of any systems that don't want to support reuse. Also the draft as written does not prevent consenting peers from doing reuse, it just fails to provide them with a simple mechanism to negotiate a mutually compatible policy. When the two ends make differt assumptions you get either waste or insufficient tickets to meet the client's needs. Let's make a small change to the code points to enable more precise negotiation and move on... -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
