A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.
Title : A DANE Record and DNSSEC Authentication Chain
Extension for TLS
Authors : Melinda Shore
>
> (1) In many cases, the client can handle this unilaterally. Are there
> examples of this kind of ticket-relevant state change that the client would
> not be aware of? When the client is aware of a state change (such as client
> auth negotiation), it can purge any tickets received before the sta
On Sat, Jun 4, 2016 at 11:42 AM, Kyle Rose wrote:
> On Sat, Jun 4, 2016 at 1:15 PM, Eric Rescorla wrote:
>
>> I don't think it's principally about discarding keying material, but
>> rather about allowing the server to attach state to a ticket and then have
>> predictable behavior. Consider the o
On Sat, Jun 4, 2016 at 1:15 PM, Eric Rescorla wrote:
> I don't think it's principally about discarding keying material, but
> rather about allowing the server to attach state to a ticket and then have
> predictable behavior. Consider the obvious case of post-handshake client
> auth (which I know
Yes, these are all reasonable points. It's purely a matter of thinking one
might want to minimize
the number of anomalies. But maybe that's not a useful goal.
-Ekr
On Sat, Jun 4, 2016 at 11:10 AM, David Benjamin
wrote:
> Wouldn't the server be required to handle such a case anyway? If it's
> d
Wouldn't the server be required to handle such a case anyway? If it's doing
post-handshake auth, it wants to do something reactive, such as based on
HTTP request or so. But that means I may have not hit an auth'd URL, saved
the session, resumed it, and then hit an auth'd URL. Or perhaps I have two
What about the choice of, randomly use any of the tickets but don’t re-use a
ticket? I am not sure why using them in a specific order is better or worse.
Even if you assign a specific ticket to a reconnect, I would expect that timing
of issues might make the server see the tickets out of order
I don't think it's principally about discarding keying material, but rather
about allowing the server to attach state to a ticket and then have
predictable behavior. Consider the obvious case of post-handshake client
auth (which I know you hate) and a client which has tickets issue before
and after
I'm not sure I follow why the additional "generation" machinery is
necessary.
What do we gain from having the server to tell us to discard a ticket
beyond what the ticket lifetime already gives? This doesn't seem an
effective way to discard key material since, unlike the ticket lifetime, we
need a
On Sat, Jun 4, 2016 at 9:21 AM, Yaron Sheffer wrote:
> Hi EKR,
>
> This is confusing: on the one hand you encourage clients to use multiple
> tickets when available, "to the extent possible use a different one for
> each new connection", and on the other hand you say that a simple way to
> follow
On 02/06/16 18:16, David Benjamin wrote:
On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni mailto:ietf-d...@dukhovni.org>> wrote:
> On Jun 2, 2016, at 10:49 AM, David Benjamin
mailto:david...@chromium.org>> wrote:
>
> I'm not sure I follow. The specification certainly spells
Hi EKR,
This is confusing: on the one hand you encourage clients to use multiple
tickets when available, "to the extent possible use a different one for
each new connection", and on the other hand you say that a simple way to
follow the Generation policy is to keep only the latest ticket, and
https://github.com/tlswg/tls13-spec/pull/493
Currently the server can send multiple tickets but we don't say anything
about the semantics.
So, say a server sends tickets T_1, T_2, T_3... T_n, and the client wants
to initiate m < n connections, should he use:
- only T_n
- T_1...T_m
- T_n, T_n-1, .
On 6/3/16 at 2:28 AM, hka...@redhat.com (Hubert Kario) wrote:
That being said, I would prefer the solution to be a compliance
test suite that checks if servers do handle correctly future
versions, future extensions and future ciphersuites correctly.
I agree with Hubert. The big question is ho
On Sat, Jun 04, 2016 at 02:26:00AM -0400, Dave Garrett wrote:
> On Friday, June 03, 2016 05:54:53 pm Joseph Salowey wrote:
> > Unfortunately, the TLS record framing is not easily compatible with having
> > multiple keys used simultaneously: because we encrypt the content type, it
> > is not possibl
15 matches
Mail list logo
