Even without the Finished computation, rejecting a CertificateRequest would
hit the same unboundedness problem the previous generation of KeyUpdate had.
Our implementation currently treats all post-handshake CertificateRequests
as a fatal error. I think the only context where we'd conceivably chan
I agre with Ilari. Currently, the way to reject a request is more than
just saying "no, thanks.".
On 10/12/2016 10:17 AM, Ilari Liusvaara wrote:
> On Wed, Oct 12, 2016 at 03:10:54AM -0400, Daniel Kahn Gillmor wrote:
>>
>> I don't think it's too much to ask that implementations be able to
>> reject
On Wed, Oct 12, 2016 at 03:10:54AM -0400, Daniel Kahn Gillmor wrote:
>
> I don't think it's too much to ask that implementations be able to
> reject a post-handshake CertificateRequest gracefully, even if they have
> no intention of ever implementing a proper Client Certificate response.
Unfortun
On Tue 2016-10-11 13:26:02 -0400, Nick Sullivan wrote:
> The major thing that this proposal achieves is that it makes post-handshake
> auth an optional part of the implementation. Instead of this, I would also
> be in favor of a simpler change that modifies the text to say that
> post-handshake Cer
implementations that want to omit it.
From: Andrei Popov
Sent: Tuesday, October 11, 2016 11:09 AM
To: Eric Rescorla ; Hannes Tschofenig
; Mike Bishop
Cc: tls@ietf.org
Subject: RE: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)
+ Mike who has additional concerns with this.
Cheers
+ Mike who has additional concerns with this.
Cheers,
Andrei
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, October 11, 2016 10:22 AM
To: Hannes Tschofenig
Cc: tls@ietf.org
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)
I think
The major thing that this proposal achieves is that it makes post-handshake
auth an optional part of the implementation. Instead of this, I would also
be in favor of a simpler change that modifies the text to say that
post-handshake CertificateRequest messages are fatal by default and only
permitte
I think it would be simpler (and deal with most cases) to only allow this
for specific application
profiles (we would then allow it in HTTP/H2, perhaps with some small -bis
RFC).
Here is a PR for this:
https://github.com/tlswg/tls13-spec/pull/680
Andrei, would this cause you any problem? My impre
Hi Nick,
given my discussion with Martin in this thread
https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like
your idea of making the post-handshake messages optional since it allows
me to develop a TLS 1.3 client that is smaller in code size.
Ciao
Hannes
On 10/08/2016 03:03 AM
On 8 October 2016 at 11:54, Eric Rescorla wrote:
> I could go either way on this. It seems like this pushes complexity from the
> client to the server.
>
> Consider the case of NST. Presently, a client which doesn't want resumption
> can just ignore NST,
> but in your proposed change, the server n
On 11 October 2016 at 14:30, Benjamin Kaduk wrote:
> So, on the balance, I think I'm starting to lean against this specific
> proposal and more towards the text changes that David wants.
Yes, I would rather not take NST or KU out of the mandatory set of 1.3
features. I'm happy to have post-hands
With respect to communicating policy from the application layer to the
TLS stack, what's wrong with David's "CertificateRequest is disallowed
by default, and the application must make a library call to enable it
for a given connection/context" proposal? It seems fairly
straightforward in terms of
I agree that "I don't like NST or KU" is not a very useful thing to add to
the spec. I added them as part of a general move towards clarity and
conservatism about which types of post-handshake messages are permissible
in TLS 1.3. Right now the spec is ambiguous about what each side of the
connectio
I could go either way on this. It seems like this pushes complexity from
the client to the server.
Consider the case of NST. Presently, a client which doesn't want resumption
can just ignore NST,
but in your proposed change, the server needs to read this extension and
then conditionally send
NST,
On Sat, Oct 08, 2016 at 04:32:32PM +, Nick Sullivan wrote:
> I'm not proposing any new post-handshake authentication mechanisms or
> anything relating to HTTP/2 renegotiation in this change. I'm simply making
> support for the existing post-handshake messages optional.
>
> With this change, if
Right, but making it an extension does not really capture the complexities
of post-handshake auth. What's needed is mostly spec text, not wire
changes. The text should say something to the effect of unexpected
CertificateRequests are always fatal to the connection. By default, all
CertificateReques
I'm not proposing any new post-handshake authentication mechanisms or
anything relating to HTTP/2 renegotiation in this change. I'm simply making
support for the existing post-handshake messages optional.
With this change, if the client does not opt in, unexpected
CertificateRequests are fatal to
On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara
wrote:
On Sat, Oct 08, 2016 at 01:03:21AM +, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake messages
> that do not contain application data and how to handle them. This PR is an
> attempt to make the story m
On Sat, Oct 08, 2016 at 01:03:21AM +, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake messages
> that do not contain application data and how to handle them. This PR is an
> attempt to make the story more explicit by adding a new post_handshake
> extension
There has been a lot of discussion lately about post-handshake messages
that do not contain application data and how to handle them. This PR is an
attempt to make the story more explicit by adding a new post_handshake
extension to TLS 1.3.
Supporting all types of post-handshake messages can requir
20 matches
Mail list logo