I concur with MT's proposal
On Wed, Mar 4, 2020 at 3:42 PM Martin Thomson wrote:
> I have a third option (mu?) which differs from previous proposals.
>
> I have been somewhat convinced by the arguments about how resumption is
> different and can tolerate the complexity of the additional
[Trimming extensively]
On Wed, Mar 4, 2020 at 7:05 PM Viktor Dukhovni
wrote:
> Reuse may never be specified, and worst case there'll be two ways to say
> "give me at most one ticket on resumption", with "at most 1" meaning
> "1" in that version of reality. The two ways being sending either "0"
Hiya,
On 05/03/2020 04:32, Watson Ladd wrote:
> It's not the usecase: it's the program. Postfix made architectural
> choices that make storing tickets allegedly expensive.
>
> I would be a lot more sympathetic if Viktor could provide actual
> measurements with actual numbers demonstrating that
On 05/03/2020 05:53, Viktor Dukhovni wrote:
> On Wed, Mar 04, 2020 at 08:32:45PM -0800, Watson Ladd wrote:
>> It's not the usecase: it's the program. Postfix made architectural
>> choices that make storing tickets allegedly expensive.
>
> These fit into a existing archicture of security-hardened
>It's not the usecase: it's the program. Postfix made architectural
choices that make storing tickets allegedly expensive.
No, it's the use-case.
We don't use postfix.
___
TLS mailing list
TLS@ietf.org
Hi Ekr,
> I don't really agree with (b) for the reasons above. It introduces new
> complications. As for (a) I believe that in practice the state that
> must be kept is quite small (in general, there will only be no
> retransmission at all and so you will only need one or slightly more
> extant
Hi Nico,
> But also, this WG has tried to accomodate things like SChannel whose API
> designs are very different from others and impinge on what is feasible in the
> protocol. E.g., reconnects are avoided.
Both Session ID-based and session ticket-based TLS resumption options are
supported in
> On Mar 4, 2020, at 21:30, Stephen Farrell wrote:
>
>
> Hiya,
>
> On 05/03/2020 02:25, Rob Sayre wrote:
>>
>>> I also note what seems like a correlation between
>>> people's yes/no opinions on this and whether or not they
>>> (or sponsors/employers) are involved in implementing
>>> a web
unless both parties agree. It takes two to agree.
What are the problems with ticket reuse? Well:
1) session linkage
2) early data doesn't get rekeyed, so you get key reuse and the early
data is replayable
In the case of SMTP, however, (1) is not a problem for obvious reasons,
and (2)
No.
FWIW, we (at my day job) run TLS 1.3 at large scale for server-to-server RPC
communication, and have seen no appreciable performance overhead from ticket
refresh on resumption.
I also have no objection to Martin's proposal.
Kyle
-Original Message-
From: TLS On Behalf Of Sean
I think several participants in these threads are taking SHOULD NOT re-use as a
MUST NOT. Servers in datacenters seem to fall outside that concern, no?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Thu, Mar 05, 2020 at 01:42:03PM -0800, Nick Harper wrote:
> In regards to the 0 -> 1 mapping:
>
> Let's assume we have a client that wishes to reuse tickets when possible
> talking to a server that is content to allow ticket reuse (since I believe
> this is the use case Viktor cares about).
On Fri, Mar 6, 2020, at 07:55, Nico Williams wrote:
> unless both parties agree. It takes two to agree.
RFC 8446 says:
Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of
a ticket allows passive observers to correlate different connections.
Are you arguing that
On Thu, Mar 05, 2020 at 05:30:04PM -0800, Benjamin Kaduk wrote:
> > No it does not, because he specifically emphasised treating 0 in the
> > resumption count as issue no tickets, whereas PR#18 says that that that
> > don't support reuse (perhaps all if that's the present consensus, until
> > such
On Thu, Mar 05, 2020 at 02:49:23PM -0800, Watson Ladd wrote:
> On Thu, Mar 5, 2020 at 12:55 PM Nico Williams wrote:
> > unless both parties agree. It takes two to agree.
>
> As far as I am aware session tickets being single use isn't enforced
> by any server right now: it's a desirable but
On Thu, Mar 05, 2020 at 02:49:23PM -0800, Watson Ladd wrote:
> My skepticism is entirely a function of this being a late breaking
> change to a relatively simple proposal, with not very much in the way
> of quantifiable evidence to back up the concern that shared cache
> contention is a big
On Wed, Mar 04, 2020 at 10:04:07PM -0500, Viktor Dukhovni wrote:
> On Wed, Mar 04, 2020 at 05:56:49PM -0800, Nick Harper wrote:
>
> > > The whole point of this discussion is that I [am] looking to avoid
> > > the need to define two overlapping extensions solving the same
> > > problem. The
On Fri, Mar 06, 2020 at 08:35:07AM +1100, Martin Thomson wrote:
> On Fri, Mar 6, 2020, at 07:55, Nico Williams wrote:
> > unless both parties agree. It takes two to agree.
>
> RFC 8446 says:
>Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of
>a ticket allows
The following errata report has been verified for RFC8422,
"Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security
(TLS) Versions 1.2 and Earlier".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6002
>It depends on the relative size of the change and the importance of
the issue.
It's a judgement call then, right? And reasonable people may disagree. But
surely given the size of the PR size is not the issue. And several folks say
it's important.
On Thu, Mar 05, 2020 at 01:56:07PM -0800, Nick Harper wrote:
> I forgot to consider that case. Thanks for explaining that. Given that, it
> sounds like MT's third option doesn't actually help the reuse case (unless
> the client has some other knowledge, presumably out of band, that the
> server
On Thu, Mar 05, 2020 at 06:15:26PM -0500, Viktor Dukhovni wrote:
> It isn't just the impact on client ticket cache processing, whatever it
> might be. Tickets can be quite large when client certs are in use,
> because various TLS APIs promise server applications the ability to
> return the client
On Thu, Mar 5, 2020 at 12:55 PM Nico Williams wrote:
>
> unless both parties agree. It takes two to agree.
As far as I am aware session tickets being single use isn't enforced
by any server right now: it's a desirable but theoretical property for
0-RTT.
My skepticism is entirely a
Hi Martin,
On Thu, Mar 05, 2020 at 10:42:09AM +1100, Martin Thomson wrote:
> I have a third option (mu?) which differs from previous proposals.
>
> I have been somewhat convinced by the arguments about how resumption is
> different and can tolerate the complexity of the additional counter.
On Thu, Mar 05, 2020 at 09:40:24PM +, Salz, Rich wrote:
> I think several participants in these threads are taking SHOULD NOT
> re-use as a MUST NOT. Servers in datacenters seem to fall outside
> that concern, no?
Indeed, RFC2119 defines SHOULD NOT:
4. SHOULD NOT This phrase, or the
On Thu, Mar 5, 2020 at 3:08 PM Nico Williams wrote:
>
> On Thu, Mar 05, 2020 at 02:49:23PM -0800, Watson Ladd wrote:
> > On Thu, Mar 5, 2020 at 12:55 PM Nico Williams wrote:
> > > unless both parties agree. It takes two to agree.
> >
> > As far as I am aware session tickets being single
On Thu, Mar 05, 2020 at 04:21:56PM -0800, Watson Ladd wrote:
> On Thu, Mar 5, 2020 at 3:08 PM Nico Williams wrote:
> > > My skepticism is entirely a function of this being a late breaking
> > > [...]
> >
> > What is late breaking to you?
> >
> > The change was proposed during WGLC. If before or
On Wed, Mar 04, 2020 at 08:32:45PM -0800, Watson Ladd wrote:
> On Wed, Mar 4, 2020 at 6:07 PM Stephen Farrell
> wrote:
> >
> >
> > Hiya,
> >
> > On 04/03/2020 16:06, Sean Turner wrote:
> > > Must the ticket reuse use case be addresses
> > > in draft-ietf-tls-ticketrequests?
> >
> > Yes. I think
On Fri, Mar 6, 2020, at 12:28, Benjamin Kaduk wrote:
> Other than this bit about giving resumption_count of zero additional
> semantics than "I am requesting zero tickets if resumption succeeds", I
> actually think this proposal is quite good. The comments I left on PR
> 18 are effectively
Hanno,
I do think you are overcomplicating things somewhat.
You can't process handshake messages out of sequence even if they are
received out of sequence (this is, of course, also the case in TLS,
it's just that the resequencing happens at the TCP layer). You have to
either drop out of order
Magnus Westerlund has entered the following ballot position for
charter-ietf-tls-05-01: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document,
Hanno,
> Hi Ekr,
>
> thanks for your prompt reply.
>
> > Thanks for your note. I don't think your proposal will be an
> > improvement. It destroys information which could otherwise be used for
> > improve round-trip and loss estimation (cf. the difference between
> > QUIC and TCP ACKs).
>
> What
32 matches
Mail list logo
