Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

I have reviewed the changes. They look good. I have some reservations about section 7 (implementation status) given that I expect it to date badly, but it isn't really doing any actual harm either. On 11 Apr. 2017 11:09 pm, "Sean Turner" wrote: > All, > > draft-ietf-tls-rfc4492bis has been revi

Re: [TLS] draft-thomson-tls-record-limit-00

acute: https://github.com/martinthomson/tls-record-limit/commit/5051d510471014f172b On 29 March 2017 at 01:00, Thomas Pornin wrote: > On Tue, Mar 28, 2017 at 06:35:24AM -0500, Martin Thomson wrote: >> I just submitted a version of the draft we've discussed a little on >> the lis

Re: [TLS] Updated Code Execution Draft

Yoav, draft submissions open as soon as the meeting starts, see here: https://datatracker.ietf.org/submit/ On 1 April 2017 at 13:49, Yoav Nir wrote: > Cute. But these documents are supposed to be sent to either the RFC editor or > the ISE directly, and no later than early March. > >> On 1 Apr 20

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

On 31 March 2017 at 09:20, Eric Rescorla wrote: >> >> I'm assuming that once the client has responded with a Certificate message >> it >> MUST send CertificateVerify and Finished afterwards and nothing else is >> permissible? That is it can't send application data or respond to other >> outstandin

Re: [TLS] The alternative idea I had for token buckets.

On 28 March 2017 at 10:57, Scott Fluhrer (sfluhrer) wrote: > Sorry, I wasn't aware that unlinkability was a requirement... Yeah, it's the only hard requirement. :) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The alternative idea I had for token buckets.

On 28 March 2017 at 10:48, Scott Fluhrer (sfluhrer) wrote: > The server recovers E_K(R) because the client sent it (along with i and the > protected message). It recovers R because it also knows K. So E_K(R) is sent directly? That would link packets. __

Re: [TLS] The alternative idea I had for token buckets.

On 28 March 2017 at 10:41, Scott Fluhrer (sfluhrer) wrote: > E_K(R); that is, R is encrypted with the server's long term key. > > (I meant to specify that...) OK, so how does the server recover E_K(R)? The point here is that it doesn't know R. ___ TL

Re: [TLS] The alternative idea I had for token buckets.

I'm sorry, but I don't understand this proposal. I'm losing you when you say E(R) without specifying the key that you are using. On 28 March 2017 at 10:21, Scott Fluhrer (sfluhrer) wrote: > Here’s how it would work: > > > > - The server has a long term secret key K, which it never gives

[TLS] draft-thomson-tls-record-limit-00

I just submitted a version of the draft we've discussed a little on the list. I don't think we concluded the discussion about what to do about block cipher padding. ... A new version of I-D, draft-thomson-tls-record-limit-00.txt has been successfully submitted by Martin Thomson and pos

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

On 24 March 2017 at 12:29, Viktor Dukhovni wrote: > I've never seen > a TLS server that has multiple chains to choose from for the same > server identity. I didn't have to look far. www.cloudflare.com will switch hit and pick RSA or ECDSA on demand: $ ./tstclnt -h www.cloudflare.com -p 443 -D -

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

The way that the UKS attack is mitigated here is counter-intuitive. It is via inclusion of the *name* in the handshake transcript and validation of that name that we get the protection we need. Victor is right to question this. This isn't a very obvious result and needs more text than a single si

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

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

[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] RFC 6066 - Max fragment length negotiation

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

Re: [TLS] Updated DTLS draft

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

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

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

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

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

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. I looked at implementing th

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. I'm fairly certain that bo

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? Most clients will explode if t

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 solution is impossible.

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

On 15 March 2017 at 09:05, Yoav Nir wrote: >A secure hash function such as the SHA-256, SHA-384, and SHA-512 > >[FIPS.180-4] MUST be used. SGTM ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

On 15 March 2017 at 08:26, Yoav Nir wrote: > That is the document that was referenced by RFC 4492 and it’s from 1998. It > doesn’t mention any hash function other than SHA-1. > > RFC 4492 said that other hash functions may be used. We’ve upgraded it to a > SHOULD. In light of recent developments,

Re: [TLS] TLS 1.3 and max_fragment_length

On 15 March 2017 at 07:44, Benjamin Kaduk wrote: >The presence of padding does not change the overall record size >limitations - the full fragment plaintext may not exceed 2^14 octets. If > >the maximum fragment length is reduced, such as by the > >max_fragment_length extension fro

[TLS] TLS 1.3 and max_fragment_length

When we added padding to TLS 1.3, we created an ambiguity with the max_fragment_length extension. Does the limit apply to len(TLSInnerPlaintext) or does it apply to len(TLSInnerPlaintext.content) (i.e., TLSPlaintext.length)? That is, does is include the padding and content type, or not? Includin

Re: [TLS] Comments on the session ticket format in TLS 1.3

On 13 March 2017 at 10:55, Brian Smith wrote: >> So, I'd prefer to bring session IDs back, and >> to arrange things so that they're always server-generated. > > Even in earlier versions, session IDs were not required with > resumption using tickets. The server sends an empty session ID and the > c

Re: [TLS] Comments on the session ticket format in TLS 1.3

On 13 March 2017 at 09:23, Ivan Ristic wrote: > - Finally, I feel that the effective removal of (visible) session IDs is a > regression. Being able to track sessions and resumption is useful to > understand traffic patterns. So, I'd prefer to bring session IDs back, and > to arrange things so that

Re: [TLS] Updating for non-X.509 certificate types

It seems like the minimum thing TLS 1.3 can do is observe that these extensions exist and that they can't be used with TLS 1.3 (yet). On 10 March 2017 at 11:43, Eric Rescorla wrote: > As noted in https://github.com/tlswg/tls13-spec/issues/722, the new fancy > TLS 1.3 Certificate structure doesn't

Re: [TLS] TLS 1.3 Record Layer Format

On 9 March 2017 at 08:46, Eric Rescorla wrote: > FWIW, I think DTLS 1.3 should just do this (and other header shortening > stuff). > I don't know of any evidence that there are policy enforcement boxes for > DTLS Definitely. I also think that DTLS 1.3 could stand to lose a few sequence number an

Re: [TLS] Certificate compression draft

On 7 March 2017 at 13:32, Viktor Dukhovni wrote: > Fewer WebPKI CAs (which are all trusted) seems like an improvement to me. > Though I doubt that compression efficiency would be a major factor in such > an outcome. Like Ryan, I would rather not create any systemic biases in favour of certain par

Re: [TLS] Certificate compression draft

and -48% at >> 95th >> percentile (with Brotli, subtract 3-5% for zlib). >> >> I think the most dramatic effect from the compression is observed for the >> certificates with a lot of SNI values, which is not uncommon. >> >> -- Victor. >> >> O

Re: [TLS] Application Data payload

On 7 March 2017 at 10:06, David Benjamin wrote: > As the spec is written right now, our interpretation is that > max_early_data_size counts the plaintext application data, not including any > encryption and record-level overhead. This aligns with (1). > > Separately, we bound how much data on the

Re: [TLS] Certificate compression draft

Hi Victor, Do you have any evidence to suggest that this reduces size in any meaningful way? Certificates tend to include both repetitious values (OIDs), and non-repetitious values (keys). On 7 March 2017 at 09:58, Victor Vasiliev wrote: > Certificate compression has been discussed on this list

Re: [TLS] Application Data payload

On 7 March 2017 at 08:43, David Benjamin wrote: > To clarify, our interpretation of the spec was that it is the encrypted > data, not unencrypted data. Well, clearly we disagree. To be clear, I don't mind much if it's the encrypted data, though we'd need to also agree if the count included the a

Re: [TLS] Application Data payload

tls/b5GpGR9QQpBV3tbxCspdHVJs8HU> I don't think that this makes sense: the true cost to the server is in the data it has to store, not process (a client has many better options for causing the server to expend CPU resources). Any data that can be ignored is cheap. On 6 March 2017 at 11:17, Martin Thomson w

[TLS] Application Data payload

The section on the maximum early data size says this: "Only Application Data payload is counted." I don't know how to interpret that. I can see arguments for counting TLSInnerPlaintext.content or all of TLSInnerPlaintext. ___ TLS mailing list TLS@ietf

Re: [TLS] "Spec Compliance" and the older TLS protocols

If you want to lawyer up on this, I think that the official interpretation is that those RFCs were obsoleted by RFC 5246 and so if you support 5246, you can do what it says and not what the older specs say. I don't think that anyone will fault you if you decide to burn all traces of DES from your

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

On 2 March 2017 at 05:44, Dang, Quynh (Fed) wrote: > OK. What is the percentage ? Even all records were small, providing a > correct number would be a good thing. If someone wants to rekey a lot often, > I am not suggesting against that. It will vary greatly depending on circumstance. Most of th

Re: [TLS] Adding an additional step to exporters

Hi Hugo, On 25 February 2017 at 03:47, Hugo Krawczyk wrote: > Martin, > > Which of these two derivation schemes are you proposing? I mean the latter of your two, where you have effectively three layers of HKDF-Expand from the master secret. master secret -> exporter secret exporter secret + e

Re: [TLS] Adding an additional step to exporters

On 24 February 2017 at 21:02, Ilari Liusvaara wrote: > This technique seems to assume there is some fixed known set of exporter > labels that are used. Since if you don't know the full set, you need to > keep the master exporter secret around anyway. This is correct. I assume here that many appl

Re: [TLS] Adding an additional step to exporters

On 24 February 2017 at 16:01, Sean Turner wrote: > So this isn’t entirely novel right I mean we did something similar wrt other > key schedules? I certainly hope it isn't novel. I'm just applying the same technique: keep independent keys independent. On 24 February 2017 at 16:09, Felix Günther

[TLS] Adding an additional step to exporters

https://github.com/tlswg/tls13-spec/pull/882 contains the longer description. In short, the existence of an exporter secret threatens the forward secrecy of any exported secret. This is a problem for QUIC and is likely to be a more general problem. The proposed fix is small: separate exporters i

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

On the interaction with TLS 1.3, we probably need a decision to be made: 1. strike TLS 1.3 from the document and only mention it in the way Joe suggests, TLS 1.3 doesn't get the CCM suites (it already has the equivalent of the GCM suites) 2. strike TLS 1.3 from the document, and add new TLS 1.3 C

Re: [TLS] TLS RSA-PSS and various versions of TLS

On 19 February 2017 at 06:25, Ilari Liusvaara wrote: > - Only the 3 TLS 1.3 variants of RSA-PSS are supported. Including in > 1.2 and certificates. > - When using RSA-PSS for SKE signature, the ciphersuite signature > algorithm is set to RSA. > - Ciphersuite signature algorithm is ignored on r

Re: [TLS] TLS RSA-PSS and various versions of TLS

On 18 February 2017 at 13:31, Dr Stephen Henson wrote: > could a TLS 1.2 server legally present a certificate containing an > RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client > present > a certificate contain an RSASSA-PSS key? NSS, when configured to do so, will do just t

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

On 16 February 2017 at 04:30, Yoav Nir wrote: > And now I’ve lost you. A moment ago I thought you were concerned that people > would fail to implement KeyUpdate. Are you now suggesting that it be removed > entirely from TLS 1.3? No. My point was that if GCM requires more updates than you can

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

On 16 February 2017 at 04:20, Yoav Nir wrote: > No, not really, but TLS is not just the web, and there are connections that > last for a long time and transfer large amounts of data. Think datacenter > synchronization. At packet-sized records 24 million records amounts to 36 > GB. That is consider

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Kenny's response here is quite informative and clarifies this somewhat. 2^24.5 (the current text) is still a big number. Though it might seem a little small, I see no practical reason to change it. In the most perverse case, that means 520MB of one octet records (23MB of actual data) before an u

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

On 15 February 2017 at 03:18, David Wong wrote: > Oups, my bad. What about if the client do send a certificate, but the server > decides not to accept it, but goes on with the connection (I think nothing > in the spec says that the server needs to terminate the connection if the > client cert is n

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

On 10 February 2017 at 16:07, Sean Turner wrote: > a) Close these two PRs and go with the existing text [0] > b) Adopt PR#765 [1] > c) Adopt PR#769 [2] a) I'm happy enough with the current text (I've implemented that any it's relatively easy). I could live with c, but I'm opposed to b. It just

Re: [TLS] PR#875: Additional Derive-Secret Stage

This is a good idea. On 10 February 2017 at 08:15, Eric Rescorla wrote: > - Address a potential issue raised by Trevor Perrin where an attacker > somehow forces the IKM value to match the label value for Derive-Secret, > in which case the output of HKDF-Extract would match the derived secret.

Re: [TLS] TLS RSA-PSS and various versions of TLS

On 9 February 2017 at 08:17, Ilari Liusvaara wrote: > If client includes RSA-PSS codepoints in its signature_algorithms, > then: > > - The server handshake signature MAY be signed using RSA-PSS in TLS > 1.2 or later. Yes, 1.2, not 1.3. > - The certificate chain MAY contain certificates signed wi

Re: [TLS] TLS RSA-PSS and various versions of TLS

On 9 February 2017 at 07:20, Yoav Nir wrote: > And it doesn’t help if the client does not provide the extension. The > extension can restrict from among the set of supported algorithms, Its > absence does not allow undefined algorithms. Since TLS 1.3 defines code points for RSA-PSS, perhaps this

Re: [TLS] PSS and TLS 1.3

On 6 February 2017 at 11:12, Nikos Mavrogiannopoulos wrote: > TLS 1.3 requiring a different key type, will provide an incentive for > them to update. I don't think that's how this works. More likely, that would become a reason not to deploy TLS 1.3 if you insist that only RSA-PSS certs are used

Re: [TLS] GREASE and TLS 1.3

On 19 January 2017 at 14:04, Kazu Yamamoto wrote: > Should we also add grease values for key_share? supported_groups code points should cover that, but if you are asking if we should spend bytes on sending shares for bogus groups, that's a question I don't have an opinion on. I guess that you *c

Re: [TLS] [Technical Errata Reported] RFC7919 (4908)

ta_search.php?rfc=7919&eid=4908 > > ------ > Type: Technical > Reported by: Martin Thomson > > Section: 4 > > Original Text > - >If a compatible TLS server receives a Supported Groups extension from >a client that includes any FFDHE group (i.e., any c

Re: [TLS] adopted: draft-thomson-tls-tls13-vectors

And it is done. I fluffed one change: NSS supports exporters now. I'll catch that when there is cause to generate a new version. PRs and issues can be opened here: https://github.com/tlswg/draft-ietf-tls-tls13-vectors The editor's copy is here: https://tlswg.github.io/draft-ietf-tls-tls13-vector

Re: [TLS] cross-domain cache sharing and 0rtt

On 4 January 2017 at 15:29, Ilari Liusvaara wrote: >> Naively, if s1 and s2 share cert and private key, and ignore the SNI, it >> seems like redirecting a full handshake would work. But I didn't think >> about it very hard. > > Actually, I think it would work if you merely have cross-valid > sele

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

On 4 January 2017 at 12:02, Benjamin Kaduk wrote: > I also had the sense that ekr noted that we didn't want to do this in the > core spec. > So, could you point me more clearly at what you would want to change in the > core spec that would allow doing the thing you want to see done in a future > d

Re: [TLS] PR#838: Clients must verify the signature of CertificateVerify

There are a lot of rebase artifacts here, but it looks good. The PR does beg the question though: how does one verify the signature and with what key? On 29 December 2016 at 02:50, Guballa Jens (ETAS-PSC/ECS) wrote: > Hi, > > here is another PR: https://github.com/tlswg/tls13-spec/pull/838 > > T

Re: [TLS] WGLC for draft-ietf-tls-ecdhe-psk-aead

On 21 December 2016 at 01:45, Russ Housley wrote: > I am curious about the choice of hash function for > TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256. All of the other AES-256 > ciphersuites defined in this document that use SHA-384. Why does the one > with a truncated authentication tag use SHA-2

Re: [TLS] Harmonizing 4492bis with TLS 1.3

On 14 December 2016 at 16:42, Yoav Nir wrote: > Aren’t we going to have separate registries for 1.2 and 1.3? We don’t want > to force anyone to make the changes you had made (as part of 1.3) just to get > EdDSA..And I need to request things from IANA based on 1.2 registries. Yes, but I was thi

Re: [TLS] Harmonizing 4492bis with TLS 1.3

On 13 December 2016 at 22:47, Yoav Nir wrote: > 2. Change 4492bis: > a. no new curves for ed25519 and ed448. > b. Two new signature algorithms, and request values 7 and 8 for them. > c. new hash algorithm 0x08 and call it something like “intrinsic” This, but with a small tweak: don

Re: [TLS] PR#812: End Of Early Data as handshake

On 13 December 2016 at 12:43, Nick Harper wrote: > Right now, I believe it's legal for a client to send ClientHello, early > data, and end_of_early_data alert without reading any messages from the > server. This change would require a client to wait for the ServerHello > before sending (or not) En

Re: [TLS] PR#812: End Of Early Data as handshake

On 13 December 2016 at 12:09, Eric Rescorla wrote: > David Benjamin pointed out to me that end_of_early_data is the only place > where we transition keys on an alert and this would be cleaner if it was a > handshake message. This PR does that. It's encrypted under the same > keys, so this is large

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

On 7 December 2016 at 03:24, Sean Turner wrote: > Just a reminder that this WGLC will close on Friday December 9th. A timely reminder :) I reviewed the document and it looks pretty good. I'd have sent a PR with some minor changes to grammar. The question I wanted to ask was how we wanted to ma

Re: [TLS] Maximum Fragment Length negotiation

Kario wrote: > On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote: >> On 30 November 2016 at 05:54, Thomas Pornin wrote: >> > Any comments? >> >> I'm ambivalent on this generally: though I think that the general >> notion is OK, I'm not su

Re: [TLS] Maximum Fragment Length negotiation

On 30 November 2016 at 05:54, Thomas Pornin wrote: > Any comments? I'm ambivalent on this generally: though I think that the general notion is OK, I'm not sure about the details. In particular, you need to be clearer in your motivations: the point is to ensure that little things (really little t

Re: [TLS] Additional warnings on 0-RTT data

On 24 November 2016 at 15:11, Colm MacCárthaigh wrote: > Do you disagree that the three specific example security issues provided are > realistic, representative and impactful? If so, what would persuade you to > change your mind? These are simply variants on "if someone hits you with a stick, th

Re: [TLS] Additional warnings on 0-RTT data

On 24 November 2016 at 13:18, Colm MacCárthaigh wrote: > Can I break this into two parts then? First, do you agree that it would be > legitimate for a client, or an implementation (library), to deliberately > replay 0-RTT data? E.g. browsers and TLS libraries MAY implement this as a > safety mecha

Re: [TLS] SNI and Resumption/0-RTT

On 24 November 2016 at 09:46, Victor Vasiliev wrote: > For concreteness, I wrote a pull request that describes (2): > At this point, I think that it would be more sensible to write a separate extension draft. There are a bunch of additional cons

Re: [TLS] Additional warnings on 0-RTT data

This seems like too much text to me. Maybe some people would appreciate the reminder that replay might cause side-effects to be triggered multiple times, or that side effects are just effects and those might also be observable. But I think that those reminders could be provided far more succinctl

[TLS] Labels in HKDF-Expand-Label

The grammar for the label permits the label to be 9 octets long. That's the exact length of the prefix. That means that it is valid to use an exporter with an empty label string. That seems dangerous. I propose that we require at least one octet: https://github.com/tlswg/tls13-spec/pull/774 __

Re: [TLS] Draft 18 review : Message splitting and interleaving

On 23 November 2016 at 10:24, Eric Rescorla wrote: >> [EncryptedExtensions Certifi] >> [cateRequest Certificate Cer] >> [tificateVerify Finished] > > > Yeah, that's how this works in NSS. To be clear, NSS buffers an entire flight of messages and then sends them. It might fragment things be

Re: [TLS] Draft 18 review : 0-RTT

On 23 November 2016 at 06:07, Olivier Levillain wrote: > > In 4.2.8 (P.47), the server receiving early_data "can behave in one of > two ways"... followed by three cases. Beside the typo, the first case > could be phrased differently. Actually, it reads > >- Ignore the extension and return n

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On 21 November 2016 at 14:13, Eric Rescorla wrote: >> IMO, the compression methods section of ClientHello should be ignored as >> mentioned by Martin Rex. > > I'm not seeing any good reason for this. We don't want anyone to offer > compression and it's not > like it's difficult for 1.3 implementat

Re: [TLS] Confirming consensus: TLS1.3->TLS*

On 18 Nov 2016 21:10, "Peter Gutmann" wrote: > Which is kind of odd, because the consensus on the list when it was debated > here a while back was to not call it 1.3. Some of us stayed quiet for that conversation. I might speculate that it was because it wasn't a constructive discussion. In the

Re: [TLS] Confirming consensus: TLS1.3->TLS*

On 18 November 2016 at 11:12, Sean Turner wrote: > - Leave it TLS 1.3 There is no point in re-litigating this decision. The consensus call was pretty clear in the room. Perhaps the question would have been better phrased as: "does anyone have new information that would suggest those present at

Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header

Okay, so you are saying that every packet has the same number? On 15 Nov 2016 6:30 PM, "Fossati, Thomas (Nokia - GB)" < thomas.foss...@nokia.com> wrote: > On 15/11/2016 09:20, "TLS on behalf of Martin Thomson" > wrote: > >This means that you can guarantee p

Re: [TLS] extending the un-authenticated DTLS header

On 15 November 2016 at 18:11, Nikos Mavrogiannopoulos wrote: >> I'm not seeing quite enough information here to implement this. How >> does a server know which of the many HOTP keys it has are in use? >> Surely you can't use the same HOTP key with every client. > > Not sure I understand the quest

Re: [TLS] extending the un-authenticated DTLS header

On 15 November 2016 at 17:34, Fossati, Thomas (Nokia - GB) wrote: > The draft proposes two ways to allocate the identifier (see 3rd para of > https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1): > 1. Server decides unilaterally a value that is fixed for the duration of > the session (Se

Re: [TLS] extending the un-authenticated DTLS header

On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos wrote: > TLDR; the privacy offered by this extension is the same as the privacy > of DTLS over UDP. I disagree. All the privacy considerations of the QUIC connection ID apply here. It would probably pay to follow that discussion. If the int

Re: [TLS] extending the un-authenticated DTLS header

On 15 November 2016 at 10:16, Eric Rescorla wrote: >> I'd be interested in an analysis of the potential privacy >> impacts of this. Isn't this more or less the same as doing >> SPUD-for-DTLS? (If not, sorry for dragging in controversy:-) > > > It would no doubt depend what you put there. Which i

Re: [TLS] Fwd: New Version Notification for draft-thomson-tls-tls13-vectors-01.txt

On 15 November 2016 at 09:59, Kazu Yamamoto wrote: > I would be nice if this example includes secp256r1 instead of (or in > addition to) x25519 as I guess that many TLS 1.3 implementations > implement secp256r1 first. That should be easy to add. I can add a 1-RTT handshake with P-256. In the in

Re: [TLS] extending the un-authenticated DTLS header

On 15 November 2016 at 09:28, Eric Rescorla wrote: > One way to split the difference between these two would be to use an > extension to negotiate the encrypted record format. Yes, that could work. It would need special rules for 0-RTT, but in theory a negotiated extension could do anything to

Re: [TLS] extending the un-authenticated DTLS header

On 14 November 2016 at 21:58, Nikos Mavrogiannopoulos wrote: > For draft‐mavrogiannopoulos­‐dtls­‐cid­‐00 and we needed to extend the > DTLS un-authenticated part of the DTLS record header with an additional > field. That works well if this is the only draft ever extending the > DTLS record heade

[TLS] Fwd: New Version Notification for draft-thomson-tls-tls13-vectors-01.txt

draft-thomson-tls-tls13-vectors-01.txt To: Martin Thomson A new version of I-D, draft-thomson-tls-tls13-vectors-01.txt has been successfully submitted by Martin Thomson and posted to the IETF repository. Name: draft-thomson-tls-tls13-vectors Revision: 01 Title: Ex

Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5

These are intentionally very conservative. Having implemented this, I find it OK. The text cites its sources. Reading those sources corrects any misapprehension. The key point here is that we want to ensure that the initial - maybe uninformed - inferences need to be for the safe thing. We don'

Re: [TLS] (strict) decoding of legacy_record_version?

On 9 November 2016 at 05:59, Brian Smith wrote: > This isn't a pervasively shared goal, though. It's good to let the browsers > police things if they want, but I think a lot of implementations would > prefer to avoid doing work that isn't necessary for interop or security. If you permit someone t

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

On 8 November 2016 at 21:08, Daniel Migault wrote: > TLS enable curve negotiation but not for code point. This makes restrictions > on code points hard to implement. As a result Endpoints MAY treat > negotiation of key sizes smaller than the lower limits as a connection error > of type insufficie

Re: [TLS] (strict) decoding of legacy_record_version?

On 8 November 2016 at 14:01, Brian Smith wrote: > Since this field isn't included in the additional_data of the AEAD in TLS > 1.3 any more, it isn't authenticated. That means an active MitM can use this > to transport up to 2 bytes of information hop-to-hop if the receiver doesn't > check it. That

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

I don't understand this. I have no problems with a recommendation (i.e., SHOULD), but you will find that many implementations will not comply with these requirements when pushed. On 8 November 2016 at 14:09, Daniel Migault wrote: >The cipher suites defined in this document are based on the A

[TLS] draft-sandj-tls-iana-registry-updates

I have reviewed this document. Other than some editorial stuff, which I have thrown into a PR, I think that this is good. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Superficial review of draft-rescorla-tls-dtls13

First of all, I think that this is pretty good work. I've implemented a version of DTLS 1.3 that you might assume based on the TLS 1.3 drafts and this is much better in several ways. The explicit ACK is nice, but I REALLY like the epoch management stuff, when I implemented it, it made things a lo

Re: [TLS] Comments on draft-ietf-tls-tls13-18

On 2 November 2016 at 15:57, Watson Ladd wrote: > A conforming client will not produce Client Hellos that trigger > multiple HRRs: it will listen the first time. Good point. And most clients will elicit none. I don't know how to force this one into a failure to interoperate without taking the ap

Re: [TLS] Comments on draft-ietf-tls-tls13-18

On 2 November 2016 at 02:45, Watson Ladd wrote: > > That sounds good. The more we can turn bugs into ones that violate the > spec, the easier it will be to get them fixed. (Hopefully) failure to interoperate >> violate the spec I know that NSS rejects multiple HRRs. I expect that Boring does to

Re: [TLS] Padding extension and 0-RTT

On 31 October 2016 at 06:58, Eric Rescorla wrote: > I'm ambivalent on this. OTOH, you're technically right, but OTOH it's just > one more conditional to save a few bytes (you need padding to exist anyway), > and if you're doing 0-RTT, you're about to send a lot more bytes anyway. 0-RTT happens wh

<    1   2   3   4   5   6   7   8   9   >