Hi list,
I just proposed a new PR (#798) concerning the text in 5.1 (Record layer),
following the discussion here (and not including the extra Handshake
constraints).
Best regards,
olivier
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailma
Hi Thomas
Your idea of defining a new similar extension is the only choice for us.
Because as per existing max_fragment_length extension in RFC 6066, client
should fail if it receives different value from server.
And also your idea of making the new extension as mandatory for TLS1.3 is good,
On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote:
> On 30 November 2016 at 05:54, Thomas Pornin wrote:
> > Any comments?
>
> I'm ambivalent on this generally: though I think that the general
> notion is OK, I'm not sure about the details.
>
> In particular, you need to be clearer
https://github.com/tlswg/tls13-spec/pull/800
In Seoul we had rough consensus (or at least apathy) to leave the supported
versions
semantics alone but tighten up the language. The above PR does that.
One point I notice we didn't discuss is whether we should require the
server to check
that ClientH
> I think if we're going to change this we should just make it an error to hav
> supported_versions and legacy_version != 0303. My preference would be to
> leave as-is, however.
I think making it a MUST NOT is enough and gives the server freedom to do what
it wants, including hunt down and for
The TLS WG has placed draft-thomson-tls-tls13-vectors in state
Candidate for WG Adoption (entered by Sean Turner)
The document is available at
https://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/
___
TLS mailing list
TLS@ietf.org
https://
On 11/29/16 at 5:28 AM, rs...@akamai.com (Salz, Rich) wrote:
Sure, here's my compressed cert. Ignore the fact that it's named "42.zip" --
see https://en.wikipedia.org/wiki/Zip_bomb
The risks of uncompressing data sent from a counterparty who has not yet been
authenticated, do not outweigh the
Asking ALL TLS implementations to change to accommodate these things
is a pretty blunt instrument. I want to be sure that this is
necessary. (FWIW, I think that this is a reasonable request, I would
probably be OK with a smaller maximum by default even.)
On 1 December 2016 at 00:22, Hubert Kario
I uploaded draft meeting minutes form the Seoul meeting to the proceedings (
https://www.ietf.org/proceedings/97/minutes/minutes-97-tls-00.txt). Thanks
to Jim Schaad for taking minutes.
Let me know if you have corrections.
Cheers,
Joe
___
TLS mailing
I took a very unofficial Twitter poll on this subject:
https://twitter.com/grittygrease/status/80364408215424
Nick
On Tue, Nov 29, 2016 at 5:47 AM Raja ashok wrote:
> I feel we can go ahead with TLS 1.3.
>
> Or else TLS 3.4, because anyway we send 0x0304 on wire for TLS 1.3.
>
>
>
> I hope
We've discussed this before, and the current state of the text is
certainly much improved. I'd like to touch on one final point.
The current text reads:
Section 4.4.1.2 (
https://tools.ietf.org/html/draft-ietf-tls-tls13-18#page-56 )
All certificates provided by the server MUST be signed
On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni
wrote:
>
> We've discussed this before, and the current state of the text is
> certainly much improved. I'd like to touch on one final point.
>
> The current text reads:
>
>Section 4.4.1.2 ( https://tools.ietf.org/html/
> draft-ietf-tls-tls13-
Nick Sullivan writes:
>I took a very unofficial Twitter poll on this subject:
>https://twitter.com/grittygrease/status/80364408215424
Given the lack of context for the question (an out-of-the-blue query
to a random bunch of people on Twitter), I think the inevitable TLSy
McTLSface (given as
> On Nov 30, 2016, at 10:51 PM, Eric Rescorla wrote:
>
>
>
> On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni
> wrote:
>
> The current text reads:
>
>Section 4.4.1.2 (
> https://tools.ietf.org/html/draft-ietf-tls-tls13-18#page-56 )
>
>All certificates provided by the server MUST
Viktor Dukhovni writes:
>So I'd like to see the text in the first paragraph changed to a SHOULD or
>worst-case a qualified "MUST whenever possible".
Why is that whole thing even there in the first place? From the previous
discussions where this came up, the pretty much universal consensus was
> On Nov 30, 2016, at 11:28 PM, Peter Gutmann wrote:
>
> I actually completely agree with Timothy Jackson's recent posting:
>
> After 15 years, everyone but us still calls it SSL. We need to
> admit that we lost the marketing battle and plan for a world where
> everyone calls “TLS X” “S
> On Nov 30, 2016, at 11:36 PM, Peter Gutmann wrote:
>
> Why is that whole thing even there in the first place? From the previous
> discussions where this came up, the pretty much universal consensus was that
> people were ignoring the requirement because it served no obvious purpose
> but b
17 matches
Mail list logo
