On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote:
> On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote:
> > Any ClientHello with > 200 Cipher suite code points indicates fairly insane
> > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour.
>
> and which part of
On Thu, Jul 21, 2016 at 07:08:04PM +0200, Martin Rex wrote:
> Martin Thomson wrote:
> > On 21 July 2016 at 18:41, Martin Rex wrote:
> >>A server that implements this extension MUST NOT accept the request
> >>to resume the session if the server_name extension contains a
> >>
That argument seems like it would apply to all post-handshake authentication,
unless there's something different about that.
-Original Message-
From: Martin Rex [mailto:m...@sap.com]
Sent: Thursday, July 21, 2016 7:08 PM
To: Martin Thomson
Cc: m...@sap.com;
Martin Thomson wrote:
> On 21 July 2016 at 18:41, Martin Rex wrote:
>>A server that implements this extension MUST NOT accept the request
>>to resume the session if the server_name extension contains a
>>different name. Instead, it proceeds with a full handshake to
>>
Ah, I was seeing the lower-case version in Appendix A from a quick search.
Yes, that one is upper-case.
Still, that seems simple enough to handle in whatever discussion of how
resumption affects this. If they remain in effect across a resumption, any
name in that set could reasonably be
I assume you're referring to Section 3, SNI's ServerNameList MUST NOT contain
more than one name of a given type? Technically, we're not violating that,
since we're not changing SNI. The client requests a single identity in the TLS
handshake, which the server provides. Additional identities
Mike Bishop wrote:
>
> That means we now have a proposal for carrying both client and server
> certificates above TLS, found at
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs.
>
> We have also discussed that it might be preferable to pull part of this
> capability back
On Thursday, 21 July 2016 12:25:48 CEST Peter Gutmann wrote:
> Martin Rex writes:
> >Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour.
> >X.509v3 certificates can theoretically include CAT MPEGs and amount to
> >megabytes.
>
> We really need a TLS scanner
Martin Rex writes:
>Limiting PDU sizes to reasonably sane sizes is perfectly valid behaviour.
>X.509v3 certificates can theoretically include CAT MPEGs and amount to
>megabytes.
We really need a TLS scanner that does this just to see what happens. When I
created that cat-MPEG
On Thu, Jul 21, 2016 at 10:19:34AM +, David Benjamin wrote:
> On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk wrote:
>
> > On 07/20/2016 05:01 AM, Hanno Böck wrote:
> > > On Wed, 20 Jul 2016 11:20:46 +0200
> > > Hubert Kario wrote:
> > >
> And as Hubert
On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote:
> Hubert Kario wrote:
> > Martin Rex wrote:
> >> Forget TLS extensions, forget ClientHello.client_version.
> >> Both in fundamentally broken, and led to Web Browsers coming up
> >> with the "downgrade dance" that is target of the POODLE
On Wed, Jul 20, 2016 at 5:43 PM Benjamin Kaduk wrote:
> On 07/20/2016 05:01 AM, Hanno Böck wrote:
> > On Wed, 20 Jul 2016 11:20:46 +0200
> > Hubert Kario wrote:
> >
> >> so it looks to me like while we may gain a bit of compatibility by
> >> using extension
Hi, folks -
Martin and I had come previously to the TLS WG to discuss our work with
handling client certificates at the HTTP layer. Based on that discussion, we
revised our model to cover signatures of an exporter value and carry the proof
in an HTTP/2 frame. During BA, the HTTP WG expressed
Congrats to all involved!
spt
> On Jul 19, 2016, at 10:01, rfc-edi...@rfc-editor.org wrote:
>
> A new Request for Comments is now available in online RFC libraries.
>
>
>RFC 7924
>
>Title: Transport Layer Security (TLS) Cached
>Information Extension
On Wed, Jul 20, 2016 at 01:42:58AM -0400, Hugo Krawczyk wrote:
> Without taking a position on the implementation issues, I am in favor of
> Option A with a dedicated context value (and an explicit name "PSK
> Context") as this makes clear the function of this value. Relying in
> Finished makes it
15 matches
Mail list logo