On 18 March 2017 at 00:26, Ilari Liusvaara wrote:
> Also, 1200 bytes of packet payload should be feasible. That's
> well within IPv6 minMTU, and also within reach of virtually all
> IPv4 links.
This was the rationale in QUIC. Most links support an MTU of that
size, if only because they have to
On Fri, Mar 17, 2017 at 04:37:59PM +0100, Thomas Pornin wrote:
>
> > Also, in TLS 1.3, certificate messages are considerably more
> > complicated. I don't think streaming processing of recommended-to-
> > support stuff is even possible.
>
> Streaming processing is ill-supported and on the decline
On Fri, Mar 17, 2017 at 04:44:48PM +0200, Ilari Liusvaara wrote:
> The mere thought of someone implementing streaming processing in
> C scares me. I think BearSSL autogenerates that code.
Yes, actual code is in a custom Forth dialect, which is compiled to
token-threaded code executed by a C interp
On 03/17/2017 11:57 AM, Martin Thomson wrote:
> This is apparently a big deal for people building little things with
> TLS in them. Hannes knows better than I do. On the web, this
> extension basically doesn't exist (for the aforementioned reasons, in
> part, also because browsers historically di
Fixed in:
https://github.com/tlswg/tls13-spec/commit/40e6e0cdfedf602db0e31ff62b8d4af6d47fc631
-Ekr
On Fri, Mar 17, 2017 at 7:38 AM, Peter Wu wrote:
> Hi,
>
> In the current draft, the Early Data Indication extension
> (https://tools.ietf.org/html/draft-ietf-tls-tls13-19#section-4.2.7)
> refers
Hi Martin,
we suggested it in Section 6 of
https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00 and
Thomas also made a proposal in the same direction not too long ago as
well, see https://www.ietf.org/mail-archive/web/tls/current/msg22058.html
Ciao
Hannes
On 03/17/2017 07:24 AM, M
Here are my 5 cents: we implement this extension in our mbed TLS stack
and we consider it quite important for IoT devices that have limited
amount of RAM. The DTLS/TLS profiles for IoT RFC also recommends the use
of this extension and we discussed this in the DICE WG and there was no
objection agai
On Fri, Mar 17, 2017 at 02:33:44PM +0100, Thomas Pornin wrote:
> On Fri, Mar 17, 2017 at 11:21:12AM +, Peter Gutmann wrote:
> > However, this then leads to a problem where it doesn't actually solve
> > the constrained-client/server issue, if a client asks for 2K max
> > record size and the serv
Hi,
In the current draft, the Early Data Indication extension
(https://tools.ietf.org/html/draft-ietf-tls-tls13-19#section-4.2.7)
refers to Appendix B.3.4 for the use of the max_early_data_size.
I cannot see how that appendix makes it easier to understand how the
field is supposed to be used. Sho
On Fri, Mar 17, 2017 at 11:21:12AM +, Peter Gutmann wrote:
> Martin Thomson writes:
>
> >Plaintext records don't have any such limits. I explicitly excluded them.
>
> Hmm, it's somewhat disguised in the text, technically all records are
> "protected records" (if you use EMS, everything is a
On Fri, Mar 17, 2017 at 11:32:16AM +, Matt Caswell wrote:
> On 17 March 2017 at 00:03, Martin Thomson wrote:
> > On 17 March 2017 at 10:58, Matt Caswell wrote:
> >> In DTLS1.3 the cookie is now (potentially) much larger and appears much
> >> later in
> >> the ClientHello, making it much more
On Fri, Mar 17, 2017 at 11:21:12AM +, Peter Gutmann wrote:
> However, this then leads to a problem where it doesn't actually solve
> the constrained-client/server issue, if a client asks for 2K max
> record size and the server responds with a 4K hello then it's going to
> break the client even
FWIW, the IETF LC for this has ended now and I plan
to send the approval message for the uplift to the
secretariat later today.
Thanks,
S.
On 16/03/17 20:33, Yoav Nir wrote:
> Oh, sorry. I missed that it was Informational.
>
> In that case there’s just the issue that it has ECDH ciphersuites at
On Fri, Mar 17, 2017 at 4:32 AM, Matt Caswell wrote:
> On 17 March 2017 at 00:03, Martin Thomson
> wrote:
> > On 17 March 2017 at 10:58, Matt Caswell wrote:
> >> In DTLS1.3 the cookie is now (potentially) much larger and appears much
> later in
> >> the ClientHello, making it much more likely t
On 17 March 2017 at 00:03, Martin Thomson wrote:
> On 17 March 2017 at 10:58, Matt Caswell wrote:
>> In DTLS1.3 the cookie is now (potentially) much larger and appears much
>> later in
>> the ClientHello, making it much more likely that it will not fall
>> fully within the
>> first fragment. Thi
Martin Thomson writes:
>Plaintext records don't have any such limits. I explicitly excluded them.
Hmm, it's somewhat disguised in the text, technically all records are
"protected records" (if you use EMS, everything is at least integrity-
protected). So if you mean "this only applies to applic
On 17 March 2017 at 21:38, Peter Gutmann wrote:
> Firstly, do we have much real-world experience in using this extension? From
> the TLS-support matrix, it looks like very few implementations support this,
> does this mean few people care about it or just that it's defined in a such a
> manner th
Martin Thomson writes:
>I'd even go so far as to specify it:
>
>https://martinthomson.github.io/tls-record-limit/
Some comments...
Firstly, do we have much real-world experience in using this extension? From
the TLS-support matrix, it looks like very few implementations support this,
does this
18 matches
Mail list logo
