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 m
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
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
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 based mechanism to indicate TLSv1.3,
>
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&victim of the POO
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 notes, there may well be other intoler
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 cert, I fed it to
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 that does this ju
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
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 c
Mike Bishop wrote:
>
> I assume you're referring to Section 3, SNI's ServerNameList MUST NOT
> contain more than one name of a given type?
>
> Or are you referring to the (lower-case) must not resume if SNI and the
> certificate used in the resumed session differ?
My (online) copy of rfc6066 has a
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
>establish a new session.
If that's the
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 valid
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
>>establish a n
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; Mike Bishop ; tls@ietf.org
Su
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
> >>different na
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
17 matches
Mail list logo
