Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Tue, Feb 04, 2020 at 03:08:31PM +, Jeremy Harris wrote: > On 04/02/2020 13:56, Hubert Kario wrote: > > the thing is that getting extra ticket from the server is at most an > > inconvenience for postfix > > Isn't the giving out of needless tickets a performance cost > for the server, as

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On 04/02/2020 13:56, Hubert Kario wrote: > the thing is that getting extra ticket from the server is at most an > inconvenience for postfix Isn't the giving out of needless tickets a performance cost for the server, as well as a bandwidth cost for the network? Or are tickets zero-cost to

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Monday, 3 February 2020 06:49:15 CET, Viktor Dukhovni wrote: On Sun, Feb 02, 2020 at 09:01:45PM -0800, Eric Rescorla wrote: My point is not that servers which do not renew are not compliant but rather that TLS 1.3 has taken the position that reuse is bad and therefore we should not add an

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Mon, Feb 3, 2020 at 10:50 AM Viktor Dukhovni wrote: > > I'll read the post more closely over the next few days and attempt to > summarize where I think we are, and propose a pull request to at least > clarify the issues that motivate potential tweaks to the design. > I find the sentinel idea

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

C.4 is clearly in a context where privacy is needed and by writing "SHOULD NOT" TLS 1.3 takes instead the position there are some cases this is not required. """ C.4 . Client Tracking Prevention Clients SHOULD NOT reuse a ticket for multiple

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Feb 3, 2020, at 1:39 PM, Ben Schwartz > wrote: > > I thought in Case E the goal was that each delivery agent keeps its ticket as > persistent per-process state, to avoid re-querying the global cache. I don't recall discussing such a scenario. In Postfix the cache is shared. There is not

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Feb 3, 2020, at 12:04 PM, Ben Schwartz wrote: > > What is reuse allowing us to optimize in this case? If each process has > its own ticket cache, then reuse doesn't reduce inter-process overhead, > so what is the resource we are trying to economize? The processes do not have their own

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> E. Multiple Ticket Reuse: Client want separate tickets for concurrent connections, that are later reused > Viktor described a case in which a client is split across multiple processes, so could be convenient to have independent tickets that are all retrieved from an initial connection that

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sun, Feb 2, 2020 at 9:49 PM Viktor Dukhovni wrote: > > What I hear TLS 1.3 telling me, is to eat the porridge, after all there > are starving children in Africa, and I must set a good example lest they > too refuse to eat. > > I do not understand this point. > If so, it seems I must stuff

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sun, Feb 02, 2020 at 09:01:45PM -0800, Eric Rescorla wrote: > My point is not that servers which do not renew are not compliant but > rather that TLS 1.3 has taken the position that reuse is bad and > therefore we should not add an extension to facilitate it. Re: C.4 Clients SHOULD NOT reuse

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sun, Feb 2, 2020 at 7:40 PM Rob Sayre wrote: > On Sun, Feb 2, 2020 at 11:52 AM Daniel Migault 40ericsson@dmarc.ietf.org> wrote: > >> >> On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla wrote: >> >>> >>> >>> 1. TLS 1.3 takes the position that reuse is bad and that position >>>is for

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

I spoke with Viktor this afternoon about various scenarios being discussed on this thread. Going through the different use cases was very helpful in elucidating what functionality is appropriate. The use cases we discussed are as follows. A and B are about multiple ticket requests. C and D are

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sun, Feb 2, 2020 at 11:04 AM Nico Williams wrote: > On Sun, Feb 02, 2020 at 09:08:17AM -0800, Eric Rescorla wrote: > > I'm sorry to say that I'm not that sympathetic to this position. I > > appreciate that it's inconvenient for Postfix to have frequent writes > > to the ticket cache, but what

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sun, Feb 2, 2020 at 11:52 AM Daniel Migault wrote: > > On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla wrote: > >> >> >> 1. TLS 1.3 takes the position that reuse is bad and that position >>is for good reasons, so we shouldn't undercut it in a new >>extension. >> >> > . Appendix C.4

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On 2/1/20 at 7:43 PM, rs...@akamai.com (Salz, Rich) wrote: > +1 to what Nico says. Ditto. Cheers - Bill --- Bill Frantz| Security is like Government | Periwinkle (408)348-7900 | services. The market doesn't | 150

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sun, Feb 2, 2020 at 12:09 PM Eric Rescorla wrote: > > On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote: > > > > > I would make several points here: > > > > > > 1. RFC 8446 explicitly discourages ticket reuse > > >(https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Feb 2, 2020, at 9:53 AM, Viktor Dukhovni wrote: > > On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote: > >> If you did need a sentinel to indicate that you wanted to try to reuse >> a ticket (which you can always try if you want), it would make more >> sense to just make that

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sun, Feb 02, 2020 at 09:08:17AM -0800, Eric Rescorla wrote: > I'm sorry to say that I'm not that sympathetic to this position. I > appreciate that it's inconvenient for Postfix to have frequent writes > to the ticket cache, but what you propose to do is hoist this > implementation idiosyncracy

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sun, Feb 2, 2020 at 9:53 AM Viktor Dukhovni wrote: > Yes, that's because reuse does not need multiple tickets. Indeed long > ago upthread we discussed the fact that multiple tickets should > generally only happen on full handshakes (or at least infrequently, > rather than on each

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote: > If you did need a sentinel to indicate that you wanted to try to reuse > a ticket (which you can always try if you want), it would make more > sense to just make that sentinel be 255, etc, rather than creating two > sentinels. Sure,

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sun, Feb 2, 2020 at 6:43 AM Tommy Pauly wrote: > > On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni > wrote: > > On the other hand, the proposed sentinel value indicates “I’d like to > reuse tickets if I can”, but without any additional signaling from the > server about the support of ticket

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote: > > > I would make several points here: > > > > 1. RFC 8446 explicitly discourages ticket reuse > >(https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we > >should not be designing an extension to enable reuse. While

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni wrote: > > On Sat, Feb 01, 2020 at 08:05:28PM -0800, Watson Ladd wrote: > >>> Sorry, no idea what that above means. And is it simpler than the >>> proposal under discussion (which got some fine-tuning in early >>> feedback)? >> >> So one

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sat, Feb 01, 2020 at 08:05:28PM -0800, Watson Ladd wrote: > > Sorry, no idea what that above means. And is it simpler than the > > proposal under discussion (which got some fine-tuning in early > > feedback)? > > So one proposal in above is we treat 0 tickets as "ensure I have a valid >

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sat, Feb 1, 2020 at 7:59 PM Viktor Dukhovni wrote: > On Sat, Feb 01, 2020 at 07:04:53PM -0800, Watson Ladd wrote: > > > > The benefit of the new value of "0" is *unambiguous* signalling that > the > > > client would like to reuse the ticket if possible, and the new "255" > > > then carries

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sat, Feb 01, 2020 at 07:04:53PM -0800, Watson Ladd wrote: > > The benefit of the new value of "0" is *unambiguous* signalling that the > > client would like to reuse the ticket if possible, and the new "255" > > then carries the "We don't need no stinking tickets" signal. > > > > I'd be

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sat, Feb 1, 2020 at 5:30 PM Viktor Dukhovni wrote: > On Sat, Feb 01, 2020 at 07:53:57AM -0800, Tommy Pauly wrote: > > > Instead, it seems unclear what value the special use of 0 and 255 adds > > that wouldn’t be better served by a separate extension. > > The benefit of the new value of "0" is

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Sat, Feb 01, 2020 at 07:53:57AM -0800, Tommy Pauly wrote: > Instead, it seems unclear what value the special use of 0 and 255 adds > that wouldn’t be better served by a separate extension. The benefit of the new value of "0" is *unambiguous* signalling that the client would like to reuse the

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Jan 31, 2020, at 6: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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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. > > > > >

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.

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

ssed. > > > > 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. T

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 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, &

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 documen

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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Thu, Jan 23, 2020 at 12:57:31PM +0100, Hubert Kario wrote: > > The deployed base of Postfix servers issues multi-use tickets (always, > > there's no extension to tell me otherwise), and sends zero tickets > > on resumption, so I need to not just throw away tickets that are > > still valid. >

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Thursday, 23 January 2020 03:14:55 CET, Viktor Dukhovni wrote: On Wed, Jan 22, 2020 at 05:12:34PM -0800, Watson Ladd wrote: - either the TLS server says "here's a ticket and you MUST or MAY replace the one you already had" or - the TLS client gets to ask for no unnecessary new

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Jan 22, 2020 at 10:33:48PM -0600, Nico Williams wrote: > On Wed, Jan 22, 2020 at 05:12:34PM -0800, Watson Ladd wrote: > > > Now the first alternative would be infeasible to adopt because it would > > > require new OpenSSL callback APIs, and anyways would be a more invasive > > > change to

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Jan 22, 2020 at 05:12:34PM -0800, Watson Ladd wrote: > > Now the first alternative would be infeasible to adopt because it would > > require new OpenSSL callback APIs, and anyways would be a more invasive > > change to TLS than the ticketrequest extension makes. > > Nothing says you have

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Jan 22, 2020 at 05:12:34PM -0800, Watson Ladd wrote: > > - either the TLS server says "here's a ticket and you MUST or MAY > >replace the one you already had" > > > >or > > > > - the TLS client gets to ask for no unnecessary new tickets > > > > Now the first alternative would be

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Jan 22, 2020 at 4:56 PM Nico Williams wrote: > > On Tue, Jan 21, 2020 at 06:19:23PM +, Salz, Rich wrote: > > Viktor and I spoke in more detail. The use-case he brings up makes > > more sense to me now. The key observation is that this is not about a > > I also spoke to Viktor, and he

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Tue, Jan 21, 2020 at 06:19:23PM +, Salz, Rich wrote: > Viktor and I spoke in more detail. The use-case he brings up makes > more sense to me now. The key observation is that this is not about a I also spoke to Viktor, and he explained the motivation in detail. He really should have done

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

I support the proposal from Viktor. It is important to minimize the involved resource and provide the client the ability to explicitly inform the server its policy. As explained above, this mechanism comes with no additional complexity and address a full range of applications. See below my

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Tue, Jan 21, 2020 at 05:46:10PM -0500, Viktor Dukhovni wrote: > > 2. The additional cost of multiple tickets seems extraordinarily > >small, so I am not at all persuaded that there is enough value in > >this use case to justify adding new protocol machinery, even > >ignoring point

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote: > I would make several points here: > > 1. RFC 8446 explicitly discourages ticket reuse >(https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we >should not be designing an extension to enable reuse. While it's >

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

I would make several points here: 1. RFC 8446 explicitly discourages ticket reuse (https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we should not be designing an extension to enable reuse. While it's potentially true that some applications do not benefit from non-reuse,

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Viktor and I spoke in more detail. The use-case he brings up makes more sense to me now. The key observation is that this is not about a "client" in the conventional (or browser) sense, but rather more like a peer-to-peer kind of thing, where the client is just the one who initiates a

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Tue, Jan 21, 2020 at 03:24:50PM +, Salz, Rich wrote: > >This is clearly a subjective call, so I'll step back now. > > Yes it is. But I will say that I agree with you and think the > cleverness introduced by the "255 is magic" proposal is not warranted. Really? TLS has no sentinel

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Tue, Jan 21, 2020 at 07:17:05AM -0800, Eric Rescorla wrote: > I agree with Martin that this is unnecessary complexity. The objections stated are non-responsive, and dismiss a valid use-case. There is ZERO additional complexity. - Servers will already range-check the requested ticket

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

>This is clearly a subjective call, so I'll step back now. Yes it is. But I will say that I agree with you and think the cleverness introduced by the "255 is magic" proposal is not warranted. ___ TLS mailing list TLS@ietf.org

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

I agree with Martin that this is unnecessary complexity. In addition, I would note that switching to a new ticket *does* help even if the server is using the same STEK because it improves privacy. -Ekr On Tue, Jan 21, 2020 at 12:58 AM Martin Thomson wrote: > On Tue, Jan 21, 2020, at 16:54,

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Tue, Jan 21, 2020 at 07:57:27PM +1100, Martin Thomson wrote: > On Tue, Jan 21, 2020, at 16:54, Viktor Dukhovni wrote: > > 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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Tue, Jan 21, 2020, at 16:54, Viktor Dukhovni wrote: > 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, ...). I don't find your arguments persuasive.

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

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

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Hi, Being the last in the queue for a while I realized [1] presents a typo that may prevent my response to be seen. If that were the case, in order to move the document forward, I am re-iterating: I agree with the proposed text from David. This ends the MUST/SHOULD discussion. I also think we

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Nov 20, 2019 at 10:20 PM David Schinazi wrote: > Hi folks, > > I've chatted with Daniel and Chris offline, and I think there might > have been some miscommunication here. Please allow me to > rephrase what I think is going on, and please let me know if > this accurately represents your

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Thursday, 21 November 2019 07:35:09 CET, Rob Sayre wrote: On Wed, Nov 20, 2019 at 10:25 PM David Schinazi wrote: Hi Rob, The SHOULD from your point (1) is there to address Daniel's concern about IoT. Is the idea that excess tickets would be wasteful? I think that's true, but I would

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Thu, Nov 21, 2019 at 11:19:36AM +0800, 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 >

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

I’ve been remiss and not closed the WGLC. Stay tuned for me based on today’s WG session. spt > On Nov 6, 2019, at 00:05, Sean Turner wrote: > > All, > > This is the working group last call for the "TLS Ticket Requests" draft > available at

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Nov 20, 2019 at 11:29 PM Benjamin Kaduk wrote: > > I disagree with your premise on when BCP 14 keyword usage is appropriate. > Which is to say, I think the "SHOULD" is fine for operational concerns. BCP 14, section 6: "Imperatives of the type defined in this memo must be used with

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Nov 20, 2019 at 10:59:32PM -0800, Rob Sayre wrote: > On Wed, Nov 20, 2019 at 10:54 PM Benjamin Kaduk wrote: > > > On Wed, Nov 20, 2019 at 10:35:09PM -0800, Rob Sayre wrote: > > > On Wed, Nov 20, 2019 at 10:25 PM David Schinazi < > > dschinazi.i...@gmail.com> > > > wrote: > > > > > > >

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Nov 20, 2019 at 10:54 PM Benjamin Kaduk wrote: > On Wed, Nov 20, 2019 at 10:35:09PM -0800, Rob Sayre wrote: > > On Wed, Nov 20, 2019 at 10:25 PM David Schinazi < > dschinazi.i...@gmail.com> > > wrote: > > > > > The SHOULD from (2) is indeed not required for interoperability, but > > >

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Nov 20, 2019 at 10:35:09PM -0800, Rob Sayre wrote: > On Wed, Nov 20, 2019 at 10:25 PM David Schinazi > wrote: > > > The SHOULD from (2) is indeed not required for interoperability, but > > important > > to ensure servers put this protection in place. > > > > In that case, this issue

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Nov 20, 2019 at 10:25 PM David Schinazi wrote: > Hi Rob, > > The SHOULD from your point (1) is there to address Daniel's concern about > IoT. > Is the idea that excess tickets would be wasteful? I think that's true, but I would also not want an IoT device that crashed or performed

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Hi Rob, The SHOULD from your point (1) is there to address Daniel's concern about IoT. The SHOULD from (2) is indeed not required for interoperability, but important to ensure servers put this protection in place. That said, I've taken your suggestion to add a comma since that is clearer.

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

So, the current PR says: "Clients can use TicketRequestContents.count to indicate the number of tickets they would prefer to receive. Servers SHOULD NOT send more tickets than TicketRequestContents.count, as clients will most likely discard any additional tickets. Servers SHOULD additionally

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Thu, Nov 21, 2019 at 11:19:36AM +0800, David Schinazi wrote: > Daniel has a IoT use-case where due to memory constraints, > a client knows it can only handle a certain number of tickets, > and therefore Daniel was wondering if it would make sense to > make the requested number of tickets a

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Thanks. I've updated the PR to take MT's suggestion s/SHOULD/will/. David On Thu, Nov 21, 2019 at 1:38 PM Martin Thomson wrote: > On Thu, Nov 21, 2019, at 11:19, David Schinazi wrote: > > resources. Therefore, the number of NewSessionTicket messages sent > > SHOULD be the minimum of the

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Thu, Nov 21, 2019, at 11:19, David Schinazi wrote: > resources. Therefore, the number of NewSessionTicket messages sent > SHOULD be the minimum of the server's self-imposed limit and > TicketRequestContents.count. Thanks for doing this David. Friendly amendment: remove the SHOULD from this

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Thanks for clarifying, David! This text reflects my understanding and is fine by my. Best, Chris On Thu, Nov 21, 2019, at 11:19 AM, David Schinazi wrote: > Hi folks, > > I've chatted with Daniel and Chris offline, and I think there might > have been some miscommunication here. Please allow me

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Nov 20, 2019 at 7:20 PM David Schinazi wrote: > Hi folks, > > I've chatted with Daniel and Chris offline, and I think there might > have been some miscommunication here. Please allow me to > rephrase what I think is going on, and please let me know if > this accurately represents your

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Hi folks, I've chatted with Daniel and Chris offline, and I think there might have been some miscommunication here. Please allow me to rephrase what I think is going on, and please let me know if this accurately represents your views. Daniel has a IoT use-case where due to memory constraints, a

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote: > > Somebody should try to avoid ending up with N new tickets after > > every connection, but in could well be the client. > > Yes, I think that can and ought to be the client. The client is really the > only party that can know how

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Nov 20, 2019, at 11:48 AM, Viktor Dukhovni wrote: > > On Wed, Nov 20, 2019 at 10:40:20AM +0800, Tommy Pauly wrote: > >>>- 0x01-0xfe => client wants single-use tickets: >>>+ send up to that many tickets on full handshake, >>>+ however, generally send just 1 ticket on

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Wed, Nov 20, 2019 at 10:40:20AM +0800, Tommy Pauly wrote: > > - 0x01-0xfe => client wants single-use tickets: > > + send up to that many tickets on full handshake, > > + however, generally send just 1 ticket on resumption, or when > > replacing tickets during

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Nov 19, 2019, at 5:20 PM, Daniel Migault > wrote: > > Hi, > > Just to followup the discussion. I support Viktor,'s proposal as it provides > the ability to the client to specify what it wants rather than let the server > guess. What I am wondering is whether we are catching all

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Hi, Just to followup the discussion. I support Viktor,'s proposal as it provides the ability to the client to specify what it wants rather than let the server guess. What I am wondering is whether we are catching all possible client "policies" or whether we should consider some additional

  1   2   >