Martin Rex writes:
>I expect TLSv1.3 is going to be in a decade where IPv6 is today.
It'll be interesting to see. This certainly seems to be true for HTTP/2
a.k.a. HTTP4Google, I was expecting usage to be mostly Google-only but from
the little data I could find it appears to be even worse than
Peter Gutmann wrote:
> Thomas Pornin writes:
>>
>>TLS 1.3 is moving away from the IoT/embedded world, and more toward a Web
>>world. This is not necessarily _bad_, but it is likely to leave some people
>>unsatisfied (and, in practice, people clinging to TLS 1.2).
>
> I would go slightly further
Thomas Pornin writes:
>TLS 1.3 is moving away from the IoT/embedded world, and more toward a Web
>world. This is not necessarily _bad_, but it is likely to leave some people
>unsatisfied (and, in practice, people clinging to TLS 1.2).
I would go slightly further and say that TLS 1.3 could end up
On Tue, Mar 21, 2017 at 7:03 PM, Martin Thomson
wrote:
> On 22 March 2017 at 12:01, Eric Rescorla wrote:
> > The maximum amount of wastage in this case is E_max - E_min where E_min
> is
> > the minimum amount of expansion of any cipher suite they support.
>
> Right, I was concerned about the cas
On 22 March 2017 at 12:01, Eric Rescorla wrote:
> The maximum amount of wastage in this case is E_max - E_min where E_min is
> the minimum amount of expansion of any cipher suite they support.
Right, I was concerned about the case where this difference is
(potentially) large. That's all.
The ma
On Tue, Mar 21, 2017 at 5:44 PM, Martin Thomson
wrote:
> On 22 March 2017 at 11:09, Eric Rescorla wrote:
> > Couldn't you just use the maximum expansion you support (which
> > ought to be 16 for TLS 1.3).
>
> That leads to the same problem that we're trying to avoid, namely that
> your usable sp
On 22 March 2017 at 11:09, Eric Rescorla wrote:
> Couldn't you just use the maximum expansion you support (which
> ought to be 16 for TLS 1.3).
That leads to the same problem that we're trying to avoid, namely that
your usable space goes through the floor.
>> When compression is enabled, I can't
On Tue, Mar 21, 2017 at 4:58 PM, Martin Thomson
wrote:
> On 22 March 2017 at 00:32, Peter Gutmann
> wrote:
> > I'd earlier thought of suggesting that the record length be the
> ciphertext
> > length, not the plaintext length, but wasn't sure if there'd be much
> support
> > for it.
>
> Yep, you
On 22 March 2017 at 00:32, Peter Gutmann wrote:
> I'd earlier thought of suggesting that the record length be the ciphertext
> length, not the plaintext length, but wasn't sure if there'd be much support
> for it.
Yep, you thought right. I considered the same thing, investigated
what it would ta
Thanks Thomas, inline responses.
On 22 March 2017 at 00:15, Thomas Pornin wrote:
> Therefore, I propose to replace this paragraph:
>
> An endpoint that has no limit on the size of data they receive can
> set this value to any value equal to or greater than the maximum
> possible recor
Hi Joe,
On 03/18/2017 10:17 AM, Joseph Birr-Pixton wrote:
> With the greatest of respect, mbedtls *doesn't* implement
> max_fragment_length[1], because it doesn't fragment handshake messages
> as required by the spec. Attempts to use it with a conforming peer
> will fail to handshake.
while I am
On Tue, 2017-03-21 at 14:15 +0100, Thomas Pornin wrote:
> On Fri, Mar 17, 2017 at 05:24:09PM +1100, Martin Thomson wrote:
> > I'd even go so far as to specify it:
> >
> > https://martinthomson.github.io/tls-record-limit/
> >
> > I'll submit an I-D once the blackout ends if people are interested
>
Thomas Pornin writes:
>Maybe there should be some extra wording saying that when a "maximum record
>size" was received, with a value less than the protocol-defined limit, then
>an endpoint SHOULD strive to use minimal-sized padding in cipher suites that
>have a variable-sized padding.
I'd earlie
On Fri, Mar 17, 2017 at 05:24:09PM +1100, Martin Thomson wrote:
> I'd even go so far as to specify it:
>
> https://martinthomson.github.io/tls-record-limit/
>
> I'll submit an I-D once the blackout ends if people are interested in this.
I like this proposal. One comment, though: I think the word
s@ietf.org
Subject: Re: [TLS] RFC 6066 - Max fragment length negotiation
Thanks Yoav. I am assuming it is true for TLS1.2 also?
It would be nice to provide a mechanism for servers to do this as we are trying
to run a web server in a constrained IoT end-points with only tens of KBytes of
RAM and SSL
Thanks Yoav. I am assuming it is true for TLS1.2 also?
It would be nice to provide a mechanism for servers to do this as we are
trying to run a web server in a constrained IoT end-points with only tens
of KBytes of RAM and SSL/TLS based connection is important..
On Thu, Mar 16, 2017 at 4:48 PM, Y
Hi Joe,
thanks for pointing this out. I will talk to our mbed TLS team to find
out what the status of this issue is.
Ciao
Hannes
On 03/18/2017 10:17 AM, Joseph Birr-Pixton wrote:
> On 17 March 2017 at 16:01, Hannes Tschofenig
> wrote:
>> Here are my 5 cents: we implement this extension in our
On 18 March 2017 at 20:36, Peter Gutmann wrote:
> Incidentally, has anyone else who's implemented this dealt in the weird
> omission of 8K by using the logical value 5 that follows 1, 2, 3, 4 for 512,
> 1K, 2K, and 4K? In many cases 8K is just what you need, it halves memory
> consumption while b
On 18 March 2017 at 09:36, Peter Gutmann wrote:
> Joseph Birr-Pixton writes:
>
>>With the greatest of respect, mbedtls *doesn't* implement
>>max_fragment_length[1], because it doesn't fragment handshake messages as
>>required by the spec. Attempts to use it with a conforming peer will fail to
>>h
Joseph Birr-Pixton writes:
>With the greatest of respect, mbedtls *doesn't* implement
>max_fragment_length[1], because it doesn't fragment handshake messages as
>required by the spec. Attempts to use it with a conforming peer will fail to
>handshake.
What's the largest handshake message it sends
On 17 March 2017 at 16:01, Hannes Tschofenig wrote:
> Here are my 5 cents: we implement this extension in our mbed TLS stack
With the greatest of respect, mbedtls *doesn't* implement
max_fragment_length[1], because it doesn't fragment handshake messages
as required by the spec. Attempts to use it
Hannes Tschofenig writes:
>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
Ilari Liusvaara writes:
>In fact, in TLS 1.3, all messages except Certificate ones are likely to be
>under 2k (or 1k).
OK, in that case make the max message size 1K, or 512 bytes, or whatver you
need.
Also, TLS 1.3 as it currently stands, in a pre-standard draft, may have
messages under 2K or w
Thomas Pornin writes:
>having some guarantees on non-fragmentations may help some implementations
>that are very constrained in ROM size and must stick to the simplest possible
>code.
It's not the code size, it's attack surface. There have been endless attacks
on IP fragmentation and fragment r
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
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
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: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
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
On 17 March 2017 at 14:49, Martin Thomson wrote:
> The design I would use is much simpler. The extension would carry a
> two octet value that is the maximum size of the plaintext that the
> endpoint is willing to receive. A client could say 2^14 and that
> would allow the server to send that muc
On 17 March 2017 at 14:35, Peter Gutmann wrote:
> Why is it badly designed? I can guess that some people would prefer to have a
> mechanism for client and server to debate endlessly what the most cromulent
> fragment size is, but that's about the only thing I can see.
I looked at implementing th
Martin Thomson writes:
>In this case, max_fragment_length is so badly designed that you can actually
>argue that it has utility, but I don't consider that as a good argument for
>the general case.
Why is it badly designed? I can guess that some people would prefer to have a
mechanism for client
FWIW, this requirement is actually very old, dating back to RFC 3546. It's
not unique to TLS 1.2.
Note that for all extension types (including those defined in
future), the extension type MUST NOT appear in the extended server
hello unless the same extension type appeared in the correspon
On 17 March 2017 at 11:22, Peter Gutmann wrote:
> Is that from actually trying it with clients, or just assuming that
> implementations will do what the spec says?
I know for certain that NSS explodes. Not from trying, but from
knowing that part of the code very well. I'm fairly certain that
bo
Martin Thomson writes:
>On 17 March 2017 at 10:45, Peter Gutmann wrote:
>> In which case it might be time to update the RFC, since there's no obvious
>> reason why you can't send it from the server. Can any of the original
>> authors
>> provide a reason why it shouldn't be done by the server?
>
On 17 March 2017 at 10:45, Peter Gutmann wrote:
>
> In which case it might be time to update the RFC, since there's no obvious
> reason why you can't send it from the server. Can any of the original authors
> provide a reason why it shouldn't be done by the server?
Most clients will explode if t
Yoav
The constrained end point is server serving web pages to browsers.
Nitin
> On Mar 16, 2017, at 4:59 PM, Yoav Nir wrote:
>
>
>> On 16 Mar 2017, at 22:52, Nitin Shrivastav
>> wrote:
>>
>> Thanks Yoav. I am assuming it is true for TLS1.2 also?
>
> RFC 5246 *is* TLS 1.2. But it’s true
Nitin Shrivastav writes:
>Thanks Peter, seems like this extension is not an option.
In which case it might be time to update the RFC, since there's no obvious
reason why you can't send it from the server. Can any of the original authors
provide a reason why it shouldn't be done by the server?
Thanks Peter, seems like this extension is not an option. I guess since our
server is serving the web pages to browsers, we should be able to predict the
max amount of data that will be pushed when user submits the data on the web
page and tune the ssl buffer accordingly.
> On Mar 16, 2017, at
Nitin Shrivastav writes:
>We don't have control over the clients in our scenario which are basically
>the browsers like Chrome, IE etc.
I think a more important question would be "does any browser support this"?
Looking at:
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
it see
> On 16 Mar 2017, at 22:52, Nitin Shrivastav
> wrote:
>
> Thanks Yoav. I am assuming it is true for TLS1.2 also?
RFC 5246 *is* TLS 1.2. But it’s true for previous versions and for 1.3 as well.
>
> It would be nice to provide a mechanism for servers to do this as we are
> trying to run a web
Hi, Nitin.
In section 7.4.1.4 of RFC 5246 it says:
An extension type MUST NOT appear in the ServerHello unless the same
extension type appeared in the corresponding ClientHello.
So the answer is no. Only the client may request this.
Yoav
> On 16 Mar 2017, at 21:12, Nitin Shrivastav
> w
Hello,
This is Nitin Shrivastav, Engineering Manager at Broadcom. I have a
question on RFC 6066 Maximum Fragment Length Negotiation section
The question i have is whether it is possible for a server to initiate the
Max fragment length negotiation. The RFC describes a scenario where a
constrained
49 matches
Mail list logo
