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/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 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
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 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
This is good.
I have an editorial comment: can someone please go through and
reconcile all the use of bits and bytes throughout. It actually seems
like someone did a coin flip on every occurrence to decide which one
to use.
___
TLS mailing list
TLS@iet
On Thu, Nov 12, 2015 at 10:06 AM, Martin Thomson
wrote:
> This is good.
>
> I have an editorial comment: can someone please go through and
> reconcile all the use of bits and bytes throughout. It actually seems
> like someone did a coin flip on every occurrence to decide which one
> to use.
-01
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 5 November 2015 at 15:53, Dave Garrett wrote:
> "Trusted self-signatures SHOULD be validated before adding to a trust store
> and SHOULD NOT be re-checked at runtime." But we're getting slightly out of
> scope here, which is why I'm thinking that elaborating on this topic exactly
> as sugges
Doing it at the HTTP layer (as an authentication mechanism) is challenging,
since applications aren’t expecting to receive it that way, and moves the
authenticated exchange onto a different stream than triggered it. I know that
there’s the possibility for a layer to fake the client going away w
10 matches
Mail list logo
