Re: [TLS] RFC 6066 - Max fragment length negotiation

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.

Re: [TLS] RFC 6066 - Max fragment length negotiation

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

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.

Re: [TLS] RFC 6066 - Max fragment length negotiation

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 >>

Re: [TLS] RFC 6066 - Max fragment length negotiation

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?

Re: [TLS] Updated DTLS draft

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. This could mean a fully stateless

Re: [TLS] RFC 6066 - Max fragment length negotiation

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

Re: [TLS] Updated DTLS draft

On 13 March 2017 at 23:41, Eric Rescorla wrote: > I have just posted a new version of the DTLS 1.3 draft, updated for > draft-19. > It's still very rough with a lot of open issues (some of which are even > noted > in the draft), and no doubt contains egregious errors. > >

Re: [TLS] RFC 6066 - Max fragment length negotiation

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

Re: [TLS] RFC 6066 - Max fragment length negotiation

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,

Re: [TLS] RFC 6066 - Max fragment length negotiation

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:

Re: [TLS] RFC 6066 - Max fragment length negotiation

> 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

Re: [TLS] RFC 6066 - Max fragment length negotiation

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

[TLS] RFC 6066 - Max fragment length negotiation

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

Re: [TLS] Uplifting 5289

Oh, sorry. I missed that it was Informational. In that case there’s just the issue that it has ECDH ciphersuites at a time where 4492bis is deprecating all the other ones. But some of the ciphersuites in there are in wide enough use that it shouldn’t remain Informational. Yes, it should be

Re: [TLS] Uplifting 5289

This is actually uplift to PS. On Thu, Mar 16, 2017 at 12:16 PM, Yoav Nir wrote: > > On 16 Mar 2017, at 21:01, kathleen.moriarty.i...@gmail.com wrote: > > > > Please excuse typos, sent from handheld device > > On Mar 16, 2017, at 11:37 AM, Yoav Nir

Re: [TLS] Uplifting 5289

> On 16 Mar 2017, at 21:01, kathleen.moriarty.i...@gmail.com wrote: > > > > Please excuse typos, sent from handheld device > >> On Mar 16, 2017, at 11:37 AM, Yoav Nir wrote: >> >> >>> On 16 Mar 2017, at 17:17, Eric Rescorla wrote: >>> >>> Hi folks >>>

Re: [TLS] Uplifting 5289

Please excuse typos, sent from handheld device > On Mar 16, 2017, at 11:37 AM, Yoav Nir wrote: > > >> On 16 Mar 2017, at 17:17, Eric Rescorla wrote: >> >> Hi folks >> >> I note that we are proposing to uplift RFC 5289 to PS, despite the fact that >>

Re: [TLS] Uplifting 5289

> On 16 Mar 2017, at 17:17, Eric Rescorla wrote: > > Hi folks > > I note that we are proposing to uplift RFC 5289 to PS, despite the fact that > it > standardizes some CBC cipher suites, which the WG is looking to move away > from. I recognize that these are the only cipher

Re: [TLS] Uplifting 5289

ekr, While we’re moving the entire document to PS, we’re also following it with https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ that adds a “Recommended" column that is not (see s6) going to include marking “Y” for any of the CBC algorithms. So, I think we’re okay. spt

Re: [TLS] RFC4492bis next steps

On 16/03/17 12:52, Yoav Nir wrote: > OK, so I’ll merge the PRs tomorrow morning and start working on ekr’s > comments over the weekend. Excellent, thanks, S > > Yoav > >> On 16 Mar 2017, at 14:41, Stephen Farrell >> wrote: >> >> >> >> On 16/03/17 06:20, Yoav

[TLS] Alexey Melnikov's No Objection on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

Alexey Melnikov has entered the following ballot position for draft-ietf-tls-rfc4492bis-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [TLS] RFC4492bis next steps

OK, so I’ll merge the PRs tomorrow morning and start working on ekr’s comments over the weekend. Yoav > On 16 Mar 2017, at 14:41, Stephen Farrell wrote: > > > > On 16/03/17 06:20, Yoav Nir wrote: >> Hopefully I’ll be all done and ready to submit a new version as

Re: [TLS] RFC4492bis next steps

On 16/03/17 06:20, Yoav Nir wrote: > Hopefully I’ll be all done and ready to submit a new version as soon > as submissions are re-opened on the 27th. If we're ready sooner, I'd prefer try get that out of the way next week. I can tell to secretariat to accept updates for this draft. (I'll likely

Re: [TLS] RFC4492bis next steps

Thanks Yoav! spt > On Mar 16, 2017, at 02:20, Yoav Nir wrote: > > Hi. > > There are now three PRs pending for this draft: > https://github.com/tlswg/rfc4492bis/pulls > > These all look fine to me. > > There is also ekr’s review that requires some more changes: >

[TLS] RFC4492bis next steps

Hi. There are now three PRs pending for this draft: https://github.com/tlswg/rfc4492bis/pulls These all look fine to me. There is also ekr’s review that requires some more changes: https://www.ietf.org/mail-archive/web/tls/current/msg22628.html