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 TLS 1.3 could end up

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 support. > > Right, I was concerned about the cas

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. That's all. The ma

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 describ

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 trying to avoid, namely that > your usable sp

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 enabled, I can't

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

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 if there'd be much > support > > for it. > > Yep, you

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, investigated what it would ta

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

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 sa

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 the 3DES suites are marked as Rec

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 believe that > everyone interpre

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

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

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 padding. I'd earlie

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 word

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 https://www.ietf.org/mailman/listinfo/tls

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] Derive-Secret(foo, "bar", "")

On Tue, Mar 21, 2017 at 2:45 AM, Ilari Liusvaara wrote: > What is the correct HkdfLabel for Derive-Secret(foo, "bar", "") in > TLS 1.3 draft-19? > > I ask, because I ran into interop problems because of this, between my > implementation and OpenSSL, and I traced it to this. > > Let's assume PRF-h

Re: [TLS] DTLS 1.3 comments

On Tue, Mar 21, 2017 at 2:24 AM, Martin Thomson wrote: > 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 Actually it lives at: https://github.com/ekr/dtls13-spec

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 > me to merge and subm

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

What is the correct HkdfLabel for Derive-Secret(foo, "bar", "") in TLS 1.3 draft-19? I ask, because I ran into interop problems because of this, between my implementation and OpenSSL, and I traced it to this. Let's assume PRF-hash is SHA256 (32 bytes output) I interpret the spec so that the Hkdf

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

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 wa

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