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

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

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

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

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

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.

Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

On 3/21/17 4:20 PM, Eric Rescorla wrote: > SUBSTANTIVE > >Servers receiving a "dnssec_chain" extension in the client hello, and >which are capable of being authenticated via DANE, SHOULD return a >serialized authentication chain in the Certificate message, using the >format

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

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

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

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

[TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

SUBSTANTIVE Servers receiving a "dnssec_chain" extension in the client hello, and which are capable of being authenticated via DANE, SHOULD return a serialized authentication chain in the Certificate message, using the format described below. The authentication chain will be an

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

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

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

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,

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

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 >

Re: [TLS] Certificate compression draft

This proposal seems like a reasonable idea. One question I had is what the point of the "uncompressed length" field is: struct { uint24 uncompressed_length; opaque compressed_certificate_message<1..2^24-1>; } Certificate; I initially thought maybe it was a

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

> On 21 Mar 2017, at 14:28, Sean Turner wrote: > > >> On Mar 21, 2017, at 08:02, Eric Rescorla wrote: >> >> What we probably should actually do is make this depend on the IANA draft >> and then mark >> these Not Recommended. > > That is an option as none of

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

Hi, Thank you for the review and comments received. Given the discussion our understanding was that the consensus was to remove CCM-256 so that suites defined by the document apply both for TLS1.2 as well as for TLS1.3. The draft available on github [1

Re: [TLS] Derive-Secret(foo, "bar", "")

On Tue, Mar 21, 2017 at 05:13:23AM -0700, Eric Rescorla wrote: > On Tue, Mar 21, 2017 at 2:45 AM, Ilari Liusvaara > wrote: > > > > I believe that OpenSSL is correct. Note that this construction already > appeared in the computation for the binder keys in -18 and I

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

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

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

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

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

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

Re: [TLS] DTLS 1.3 comments

> On Mar 21, 2017, at 08:08, Eric Rescorla wrote: > > Actually it lives at: > https://github.com/ekr/dtls13-spec Assuming it gets adopted I’ll set up a WG repo for it. spt ___ TLS mailing list TLS@ietf.org

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

> On Mar 21, 2017, at 08:02, Eric Rescorla wrote: > > What we probably should actually do is make this depend on the IANA draft and > then mark > these Not Recommended. That is an option as none of the 3DES suites are marked as Recommended in the IANA draft. spt

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

On Tue, Mar 21, 2017 at 12:44 AM, Yoav Nir wrote: > Hi > > This pull request addresses most of these comments. > https://github.com/tlswg/rfc4492bis/pull/39 There is some discussion on > that PR > > Some that are not addressed, I’ve answered below. Let me know if you want

[TLS] DTLS 1.3 comments

The doc says that it is maintained at https://github.com/tlswg/dtls13-spec This is untrue (currently). I found it at https://github.com/hannestschofenig/tschofenig-ids Speaking of which, it would be really nice if there were an issue tracker that we could use for this. I hope that the working

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

Thanks Yoav, On 21/03/17 07:44, Yoav Nir wrote: > Some that are not addressed, I’ve answered below. Let me know if you > want me to merge and submit. I'd say give it a chance for one round of comments from Eric and/or others, and then submit. Or, submit before you head for an airport on your

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

Hi This pull request addresses most of these comments. https://github.com/tlswg/rfc4492bis/pull/39 There is some discussion on that PR Some that are not addressed, I’ve answered below. Let me know if you want me to merge and submit. Yoav On