d
>
>
> *From:* David Benjamin [mailto:david...@chromium.org]
> *Sent:* Thursday, November 12, 2015 12:43 PM
> *To:* Yoav Nir ; Adam Langley >
> *Cc:* Mike Bishop ; tls@ietf.org
> *Subject:* Re: [TLS] Application data during renegotiation handshake
>
>
>
> On W
, November 12, 2015 12:43 PM
To: Yoav Nir ; Adam Langley
Cc: Mike Bishop ; tls@ietf.org
Subject: Re: [TLS] Application data during renegotiation handshake
On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir
mailto:ynir.i...@gmail.com>> wrote:
> On 12 Nov 2015, at 3:32 AM, Adam Langley
&
On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir wrote:
>
> > On 12 Nov 2015, at 3:32 AM, Adam Langley wrote:
> >
> > The TLS 1.3 post-handshake client-auth was intended, as I recall, to
> > support HTTP/1.1 over TLS 1.3.
>
> No, it was (and is) presented as a way to do client certificate
> authenticat
On Wed, 2015-11-11 at 18:39 +, Mike Bishop wrote:
> A question for TLS implementation owners: During the discussion of
> the TLS 1.2 portion of https://tools.ietf.org/html/draft-thomson-http
> 2-client-certs-00, it was pointed out that HTTP/2 breaks a
> simplification of the HTTP-TLS interface
Matt Caswell wrote:
>
>
> On 12/11/15 08:23, Nikos Mavrogiannopoulos wrote:
> > On Wed, 2015-11-11 at 18:39 +, Mike Bishop wrote:
> >
> >> I know that BoringSSL explicitly requires that application data flow
> >> be stopped during renegotiation. If the HTTP working group adopts
> >> this dra
On Wednesday 11 November 2015 18:39:51 Mike Bishop wrote:
> Per the TLS 1.2 spec, that's permitted, but if
> it's not been done before, I'm afraid we may be hitting less-tested
> code paths.
It's also something that Java does and what NSS supports.
But indeed it is problematic:
https://rt.openssl
On 12/11/15 08:23, Nikos Mavrogiannopoulos wrote:
> On Wed, 2015-11-11 at 18:39 +, Mike Bishop wrote:
>
>> I know that BoringSSL explicitly requires that application data flow
>> be stopped during renegotiation. If the HTTP working group adopts
>> this draft, do the owners of other TLS imple
On Wed, 2015-11-11 at 18:39 +, Mike Bishop wrote:
> I know that BoringSSL explicitly requires that application data flow
> be stopped during renegotiation. If the HTTP working group adopts
> this draft, do the owners of other TLS implementations expect this to
> require changes in their TLS 1
> On 12 Nov 2015, at 3:32 AM, Adam Langley wrote:
>
> The TLS 1.3 post-handshake client-auth was intended, as I recall, to
> support HTTP/1.1 over TLS 1.3.
No, it was (and is) presented as a way to do client certificate authentication
with HTTP/2 not at the initial handshake.
> With HTTP/2 is
On Wed, Nov 11, 2015 at 10:39 AM, Mike Bishop
wrote:
> Since HTTP/1.1 only has one request per connection and that request is
> waiting on the client certificate to be retrieved via renegotiation, you can
> assume that the client will not send any application data between the new
> ClientHello and
A question for TLS implementation owners: During the discussion of the TLS 1.2
portion of https://tools.ietf.org/html/draft-thomson-http2-client-certs-00, it
was pointed out that HTTP/2 breaks a simplification of the HTTP-TLS interface
that some implementations may have assumed.
Since HTTP/1.1
11 matches
Mail list logo
