Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On Monday, July 13, 2015 10:30:06 am Martin Rex wrote: > Section 7.4.1.4 Hello Extensions and its subsections are clearly IRRELEVANT > for a client that does not use Hello Extensions. If you want to put it that way, sure, however they are NOT irrelevant for a _server_ that does use hello extensions. This is a direct part of the TLS 1.2 spec, therefore it is very well established that not sending the extension is a direct request for SHA1, and the server supporting this extension is required to interpret it that way. The expectations on what to do in lieu of that working are bad; that's what we want to fix here. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
On Monday, July 13, 2015 01:11:29 pm Andrei Popov wrote: > My preference would be to keep the client explicitly advertising its > capabilities, and the server strictly honoring the client-advertised > capabilities. And since the concept of "default algorithms" confuses people, > let's just get rid of it in 1.3. Conveniently, most of this WG no longer > wants SHA1 or MD5. Why not just make signature_algorithms (even more) clearly > and unambiguously MTI in 1.3? Yep. I already have that in a WIP branch at the moment. I'm merging together all my WIPs from WG discussion on the topics of alerts and certs here: https://github.com/davegarrett/tls13-spec/compare/seanfixesredux...davegarrett:alertsandcerts There's a backlog of PRs on main, so diffing on top of Sean Turner's fixes branch to reduce noise in the diff. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] DANE & TLS 1.3 (was Re: Deprecate SHA1 for signatures in TLS 1.3)
On Monday, July 13, 2015 10:47:11 pm Viktor Dukhovni wrote: > Furthermore, DANE-EE(3) clients and certificate pinning clients > cannot use anon_DH, they still a recognizable certificate from the > server, they just often don't need a recognizable signature. Even > DANE-TA(2) clients might be able to stop part-way up the chain > before the objectionable signature appears. Generic open-ended question: Is there anything else with regard to getting DANE working more smoothly that needs addressing? The current CA-based system generally sucks, and whilst not everyone agrees that DANE is currently the ideal alternative, fixing issues inhibiting it could improve things here. It really would be nice if TLS 1.3 was as DANE-friendly as possible so we can start getting support built into more clients and be less reliant on the current mess. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Let's review: draft-ietf-tls-tls13-07 (abridged)
On Wednesday, July 15, 2015 10:15:23 am Ilari Liusvaara wrote: > Let's review: draft-ietf-tls-tls13-07 Eric obviously does all the heavy lifting here, but I can reply to a few bits in the areas I've touched. > (Note: I omitted some stuff I saw recently discussed (e.g. pruning > unused crypto algorithms) or I remember discussed. I didn't explicitly > check issue list when doing this). Some of these already do have issues/PRs so I'll cite them here along with the bits I have fixed in my WIP branch for the discussions we've been having about alerts and certs. I have quite a few PRs pending review by ekr, at the moment. Note that PR 195 is under my name, but is mostly Sean Turner's commits. It's large and was bitrotted severely over time, so ekr and I had to clean it up. (the original is PR 152 with bits from 150) > > Header > > Isn't 4346 already obsoleted by 5246, which this document also obsoletes? > > 4366 seems to be jointly obsoleted by 5246 and 6066. > > 5246 and 5077 are not in numerical order, whereas the rest are. I have a pending PR that fixes this: https://github.com/tlswg/tls13-spec/pull/198/files > > 1.2. (Major Differences from TLS 1.2) > > Is this meant to be changelog or list of changes? It in current form > looks more like a changelog. It is just a changelog for now. Will definitely need to be replaced by a summary for final RFC. > > 5.2.2. (Record Payload Protection) > > There looks to be latter limits that restrict ciphertext size to 2^14 > +1024, which is smaller than 2^14+2048 here (but those limits might be > tightened further). > > As for amount of expansion needed for length-hiding, I think that being > able to represent 16384-byte record with no padding would be enough > (since record sizes cap at 16384 bytes anyway). https://github.com/tlswg/tls13-spec/issues/55 > I don't think client extensions are optional anymore in TLS 1.3 (being > required for successful handshake. I'll address this in my WIP branch for changes we've been discussing on-list. > > 6.3.1.2. (Server Hello) > > Well, at least it wouldn't be backward compatiblity hazard to remove > session_id_len, since it comes after server version. There's a comment in there from ekr asking if we should remove. The answer is a clear yes, seeing as backwards compatibility is already gone here. https://tools.ietf.org/html/rfc5246#section-7.4.1.3 The compression field was already dropped, so there's no point in having a placeholder for this unless a new placeholder is added for that too. This message does not need to maintain backwards compatibility, though. It can never be sent to a pre-TLS 1.3 client, as the client has to offer 1.3+ for the server to negotiate it. A note that this structure has changed since 1.2 is probably warranted for servers that want to also know how to send a proper one for backwards compatibility, but modifying it here isn't helpful. > > 6.3.1.4. (Hello Extensions) > Some candidates: > - truncated_hmac: Block modes have been removed. [...] > - renegotiation_info: The renego bug is fixed anyway. I have bits for both of these on my WIP branch. (not in any of my PRs pending ekr's review, yet) > > 6.3.1.5.5. (Early Data Indication) > > s/MUST not/MUST NOT/ in description of early_data with client auth? I fixed that in my WIP for all the alert and certs changes we've been discussing on list. > > A.4. (The Cipher Suite) > > Probably remove note about 001C and 001D, since lots of ciphersuites are > now reserved to avoid collisions with old ones. I have a pending PR that updates the whole section. This bit is already dropped. https://github.com/tlswg/tls13-spec/pull/180/files > > C.1. (Random Number Generation and Seeding) > > Replace SHA-1 with SHA-256? Done in my WIP along with rest of SHA-1 deprecation, as was discussed very recently. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] sect571r1
In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just the ones actually used. (per Sean's recommendation) One point of discussion between Eric and myself: sect571r1. I'm in favor of keeping it, but not very strongly. Eric suggested removing it. It does get some use, though quite a bit less than the others. The main reason I think this warrants discussion is that dropping it would drop the maximum bits here, which whilst obviously not the only factor to take into account, will possibly not be desired by some. The main arguments for ditching is probably that it might not be safely implemented and nobody actually needs something this big. So, should it stay or should it go now? Opinions? Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wednesday, July 15, 2015 05:06:37 pm Tanja Lange wrote: > > The main reason I think this warrants discussion is that dropping it would > > drop the maximum bits here, which whilst obviously not the only factor to > > take into account, will possibly not be desired by some. The main arguments > > for ditching is probably that it might not be safely implemented and nobody > > actually needs something this big. > > Removing it would drop the max number of bits but not necessarily the > max security. The exact security of binary curves is currently under > discussion. The new algorithms offer at best an asymptotic speedup -- > but 571 might be big enough to fall under asymptotics. > > I understand that libraries support it, but is it actually being used? > Does anybody have statistics on how many sites use it? It's the most used of the rarely used curves. https://securitypitfalls.wordpress.com/2015/07/14/june-2015-scan-results/ Server-side support is generally low, however a number of servers prefer to use it for ECDHE. (usage is in the same order of magnitude as P-384 & P-521, though notably less) This is down from the previous month's results but up from the month before. Server support is at a similar rate to other rarely used larger curves, but still a fraction of a percent. Nothing requires it, outright. It's important to note that the dropped range(s) of curves are listed as "MUST NOT" offer or negotiate for any TLS 1.3 implementation, though I haven't added any requirement to enforce that. Dropping it really does drop down the max size drastically, but the general CFRG consensus seems to be that nothing above curve448 is even helpful and secp521r1 would still be permitted for those that want bigger numbers. (given the CFRG opinion, even secp521r1 should be on the chopping block, then) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wednesday, July 15, 2015 05:39:26 pm Dave Garrett wrote: > It's the most used of the rarely used curves. This statement is potentially confusing, actually, because in comparison to P256 _everything_ is rarely used when it comes to ECDHE. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wednesday, July 15, 2015 06:06:37 pm Tony Arcieri wrote: > On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett wrote: > > It's the most used of the rarely used curves. > > I think all "rarely used curves" should be removed from TLS. Specifically, > I think it would make sense for TLS to adopt a curve portfolio like this: > > - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks > - NIST curves (SUPPORTED): P-256, P-384, P-521 > > All other curves should be removed, IMO. This does seem to be the growing consensus. I've submitted a PR to drop it: https://github.com/tlswg/tls13-spec/pull/200/files Unless someone can provide more detail as to why it might be needed to keep around, it looks like the WG wants rid of it. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wednesday, July 15, 2015 09:42:51 pm Dan Brown wrote: > What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By the way it > has no unexplained constants...). Has it been removed already, or does the > question also refer K-571 too? Already dropped. That's obviously not irreversible, but it's unambiguously in the virtually unused camp. The initial goal was to drop all largely unused curves. This question is just about sect571r1, which is far closer to secp384r1 & secp521r1 in terms of usage, though still notably less. If you want to argue for going with sect571k1 and not sect571r1, I don't think the WG is on-board with that. Even if we continued to allow it, I doubt much would add support for it to be worthwhile. The scan I linked to found one; literally a single server on the entire Internet, that actually supports sect571k1 for ECDHE. The stats also show 1575 "support" it, so I'm not sure what's going on there specifically. (if someone can explain this bit of those stats, please do) https://securitypitfalls.wordpress.com/2015/07/14/june-2015-scan-results/ Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wednesday, July 15, 2015 10:42:54 pm Dave Garrett wrote: > The stats also show 1575 "support" it, so I'm not sure what's going on there > specifically. (if someone can explain this bit of those stats, please do) Actually, now that I think about it, it could just be that every single implementation out there prioritizes sect571r1 over sect571k1. So, it has low support, but everything that supports it defaults to sect571r1. Note that both are supported by an order of magnitude fewer servers than secp384r1 and secp521r1. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
On Wednesday, July 15, 2015 10:31:12 pm Tony Arcieri wrote: > Binary curves in particular are showing warning signs of potential future > security issues: > > https://eprint.iacr.org/2015/310.pdf > > I think even if we don't completely pare down the TLS curve portfolio to > the list I suggested, if nothing else I would like to see binary curves > removed. As of today's draft version on GitHub [0], the only curves permitted in TLS 1.3+ are: secp256r1, secp384r1, secp521r1, & sect571r1 NIST naming [1] of these: P-256, P-384, P-521, & B-571 The other 571-bit is sect571k1 / K-571 (already cut). NIST notation [2] for these names: "P" denotes prime, "B" denotes binary, and "K" denotes Koblitz If there's sufficient evidence that binary curves are likely to be unsafe in the future, then I would certainly consider that to be an additional argument to cut sect571r1. Thus far, I haven't seen much of an argument to keep it. [0] https://tlswg.github.io/tls13-spec/#negotiated-groups [1] https://tools.ietf.org/html/rfc4492#appendix-A [2] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf Side question: what is the meaning of the "r" in the naming convention we use? (e.g. secp521r1, & sect571r1 vs. sect571k1) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Alerts & Certs - PR #201
https://github.com/tlswg/tls13-spec/pull/201 I've finished up the WIPs I had been working on for the various discussions we've been having on-list and submitted a PR. There's a lot in there, so review and comments are welcome. Almost all of this has been discussed here at some point to some degree, though across more than a few different threads, and not necessarily in the detail in the PR. Main points: * More explicit alert expectations * Deprecate SHA-1 and allow as fallback only * Make signature_algorithms & supported_groups extensions mandatory (for applicable cipher suites) * Shift final decision to abort due to unsupported certificate chain to the client * Require SNI for application protocols for which it is meaningful (this was discussed a while ago) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS 1.3 - method to request uncached shared secrets
Brian Smith posted an RFE to GitHub a few months ago requesting "A mechanism is needed to indicate that a session will not be resumed": https://github.com/tlswg/tls13-spec/issues/137 The goal is to provide a simple way for either endpoint to request that the master secret be forgotten ASAP to provide a greater assurance of confidentiality. I've written up a short proposal with idea about how I'd suggest going about this: https://github.com/tlswg/tls13-spec/compare/master...davegarrett:resetnotify The idea is to simply add a new "reset_notify" alert (generally a warning) which may be sent by either endpoint as soon as record protection is available, after which both endpoints would stop caching shared secrets after completion of traffic key completion. This could be sent right from the start, at the end of a connection just prior to a standard "close_notify", or at any point in between. This seems like a simple route that does what is specified in issue #137 without the creation of any new extensions or messages; just one new alert value. Comments? Suggestions? Any reason this would break everything? No PR yet. Just a WIP branch to spec out the idea, so far. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - method to request uncached shared secrets
On Fri, Jul 17, 2015 at 9:37 PM, Dave Garrett wrote: > Brian Smith posted an RFE to GitHub a few months ago requesting "A > mechanism is needed to indicate that a session will not be resumed": > https://github.com/tlswg/tls13-spec/issues/137 [...] > I've written up a short proposal with idea about how I'd suggest going > about this On Saturday, July 18, 2015 12:50:40 am Eric Rescorla wrote: > I don't think this is that useful or practical with the current structure > of TLS 1.3. [...] > - Because the resumption master secret is cryptographically independent > of the master secret that initiated the connection, its existence in the > server's database or in a ticket isn't a threat to the originating > connection. > > - The server can opt not to allow resumption by declining to provide > a NewSessionTicket message. > > - The client has the option of never initiating a new connection with the >provided ticket (assuming that the server opts to supply one). Note >also that because the ticket is encrypted with the original traffic keys, >if the client never tries to resume the connection, the ticket never >appears on the wire (which is relevant for self-encrypted tickets, but >not so much for tickets which are database lookup keys). Ok, it looks like this late night idea isn't really needed anymore for at least this set of use-cases. On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote: > This is not really what I was intending when I suggested the feature. I was > intending for their to be an indication, in the ClientHello, that the > server should not do any of the work that it would normally do to make the > session resumable. That is, the server MUST NOT create a session ticket, > and the server MUST NOT add the connection to any session cache, the server > SHOULD forget the epheneral (EC)DHE key and master secret ASAP during > handshaking. (And, so should the client.) Ah, so just a simple empty extension would suffice for your main concern. I went with a simple alert to satisfy your 3rd point in the RFE along with 1 and 2. > In the context of web browsers, I believe that the Tor Browser would prefer > to have this, since it disables session resumption to prevent the leaking > of the tracking identifier inherent in it. It would also be useful for any > (non-browser) application for which a 1-RTT handshake per connection is > good enough, which is probably most applications, especially many > server-to-server applications. Ok, then I'll move the other little wording fixes/simplifications in there into my main WIP branch and set this idea aside for the time being. If the ability to easily request an ephemeral TLS session at-will sounds particularly useful to anyone, then we can discuss it further and I could submit a PR. Thanks, Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - method to request uncached shared secrets
On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote: > This is not really what I was intending when I suggested the feature. I was > intending for their to be an indication, in the ClientHello, that the > server should not do any of the work that it would normally do to make the > session resumable. Ok, I might as well write up the generic solution then: https://github.com/tlswg/tls13-spec/compare/master...davegarrett:sessionrequest This is an extension to allow a client to optionally request a specific session ticket lifetime. It can request a zero lifetime to disable session resumption and have the server not cache anything, request a max uint32 lifetime to request the maximum lifetime the server is willing to offer (up to the server if it wants to allow a longer lifetime than default), or request any specific lifetime (again, honoring is optional). The extension is just a single uint32 value; including overhead, this is a total of 8 bytes. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Does the ServerHello really need unencrypted extensions at all?
There's two issues (basically duplicates) for this topic, as well as an inline
TODO.
https://github.com/tlswg/tls13-spec/issues/66
https://github.com/tlswg/tls13-spec/issues/72
https://tlswg.github.io/tls13-spec/#server-hello
The current expectation is to separate extensions into unencrypted and
encrypted, with:
"The ServerHello MUST only include extensions which are required to establish
the cryptographic context."
The rest then go into the new EncryptedExtensions message.
Are there really any extensions that this applies to? What extension couldn't
we get away with encrypting? As soon as ServerKeyShare is sent, the client
should have enough information to decrypt the encrypted extensions message.
Site note: ServerKeyShare could probably just be merged into ServerHello at
this point:
struct {
ProtocolVersion server_version;
Random random;
CipherSuite cipher_suite;
select (DH) {
case true:
NamedGroup group;
opaque key_exchange<1..2^16-1>;
case false:
struct {};
};
} ServerHello;
Even if an extension is desired to set up a cryptographic context, then ideally
you'd want to set up a basic extension-less one _first_, send an encrypted
extensions message containing that needed extension, then send a second
encrypted extensions message using the new context using the extension. The
goal is to encrypt all the things, per TLS WG charter, so I don't see a point
in allowing unencrypted extensions in ServerHellos at all anymore.
Is there some reason why such a plan wouldn't be able to work? Having two
places to put server extensions is bound to cause mistakes.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A la carte handshake negotiation
Since the last time I posted it here, I've made some changes. Everything is rebased on top of what is now PR #201 (it's not really severable from that). https://github.com/davegarrett/tls13-spec/compare/alertsandcerts...davegarrett:alacarte Now that resumption is PSK-based, some of the language might need tweaking for that, but I not everything is sorted out for PSK-based resumption yet. (there's TODOs in the draft; e.g., doesn't yet say what cipher suites are to be used for resumption) Other than that, it's at a state that (with PR #201) I could submit a PR if we can agree that this is the general path forward. The highlights of this proposal, for those who didn't follow the previous (long) discussions on the topic: * All DH, DHE, ECDH, RSA, and DSS cipher suites are deprecated. (some could still be offered for backwards compatibility, just like before) * The only compatible cipher suites would be those with a handshake portion of ECDHE_ECDSA, ECDHE_PSK, PSK, or ECDHE_anon. (there is an exception in there for completely new stuff, which will essentially be amending this anyway) * All ECDHE_ECDSA suites can negotiate ECHDE/DHE & ECDSA/DSA/RSA via the existing extensions. (no new extensions need to be defined to do this) * Likewise, ECDHE_PSK and ECDHE_anon can negotiate ECHDE/DHE via the existing extension. * A new standards track RFC to promote ECDHE suites from informational is needed, but that was already true. * In addition to reducing combinatorial nonsense with the suites, it results in deprecation of existing DHE suites in favor or DHE done via ECDHE labeled suites only with strong groups. This is the general result of previous discussions. The alternate route that came up was just to ditch the concept of cipher suites entirely and add a new extension to negotiate the AEAD cipher/hash to use with the existing extensions. There's nothing that would preclude moving to that more extreme route if this were to be accepted first, as ECDHE/DHE negotiation via the extension would be needed for that too. I think the WG is more in favor of the route proposed in this changeset at the moment, though. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - method to request uncached shared secrets
On Sunday, July 19, 2015 04:49:10 pm Eric Rescorla wrote: > On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith wrote: > > Great. I was misunderstanding. Here's the part that is not is still not > > clear to me: Is the SessionTicket extension still to be used or not? It > > seems not, AFAICT. If the SessionTicket extension were to be used, then > > everything would work perfectly as Viktor suggested in his message: the > > absense of the SessionTicket extension in the ClientHello would be the way > > that a client can indicate that it doesn't want the session to be cached. > > No, it's not used. This draft spec explicitly obsoletes RFC 5077. (listed up top) https://tools.ietf.org/html/rfc5077#section-3.2 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - method to request uncached shared secrets
On Sunday, July 19, 2015 05:03:56 pm Viktor Dukhovni wrote: > In the current 1.3 draft, there is indeed no client signal. [...] > The fix would be for the client to send an empty extension of some > sort to signal its desire to elicit a session ticket. Why is the SessionTicket TLS Extension being deprecated at all? Sure, obsolete the RFC, but include the same extension in the TLS 1.3 spec with the same semantics for requesting a ticket from the server (0-length to request). This could be backwards compatible easily enough. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - method to request uncached shared secrets
On Sunday, July 19, 2015 05:28:27 pm Brian Smith wrote: > It depends on how the server implements tickets. The server could implement > tickets the same way that it implements session ID-based resumption. That's > not a good idea, but I don't think the spec should prohibit that type of > implementation either since it unenforceable. Thus, because of that > possibility, it is valuable to have the client be able to say "don't cache > the session" and/or limit the session's lifetime, so the client can help > direct the level of forward secrecy for the session. Right now, only the > server has a say in how long a session will be forward-secret. > > Note also that the NewSessionTicket extension precedes any application > data, so without a way to prevent an unwanted NewSessionTicket message from > being sent, the client has to waste effort and time to consume the > NewSessionTicket before it can do anything useful. If the general ticket lifetime request route is not needed, here's the simplest route: just don't drop the Session Ticket extension. https://github.com/tlswg/tls13-spec/compare/master...davegarrett:recycleticketextension This keeps it with the same semantics for requesting a ticket, thus allowing TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2 servers with no additional effort. TLS 1.3 sessions would be resumed using the new PSK-based method and TLS 1.2 sessions would be resumed using the old session ticket extension. Should I submit this as a PR? It seems like the obvious route if all we want is to just keep the ability for a client to not request a ticket. No need to write a new extension at all. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] crypto computations & lifetimes clarifications (was: TLS 1.3 - method to request uncached shared secrets)
On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote: > I think perhaps you have misunderstood the forward secrecy properties of the > current draft. Unlike TLS 1.2 and previous, the current draft has a separate > resumption master secret which is independently derived from the master > secret used for the connection keys in the original connection. This means > that if you don't resume the connection, you have forward secrecy for the > original connection regardless of whether the server stores the session in > the session cache or sends the client a ticket. We've got lots of keys and secrets now. Could you please clarify the exact points where these are each to be discarded? If I am understanding it correctly, the master_secret, prior intermediate secrets, and finished_secret are to be discarded as soon as the keys, resumption_secret, and possibly exporter_secret (which currently has no explanation in the doc) are derived, the handshake is finished, and we're ready for application traffic? It would help if you provided a table/chart laying out the timeline of secret & key lifetimes, from derivation to discard. It should state in the spec explicitly what needs to be kept around for how long and require things be discarded as soon as viable. I think these various values need to be named more consistently in the doc to make searching for them easier. For example, "resumption_secret" is used in the computation part but the words "resumption master secret" are used when actually using this value. (also noted in issue #191 by Martin Thomson) I've pushed a small PR to correct this case along with a few tweaks that I think makes it a bit clearer. https://github.com/tlswg/tls13-spec/pull/205 Also, some other questions about various computations: https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-7.1 https://tlswg.github.io/tls13-spec/#key-schedule HKDF(,,,) doesn't seem to be fully defined here, just HKDF-Expand-Label(,,,) which is based on HKDF-Expand(,,) from RFC 5869. Could you please clarify this? Why is finished_secret derived from extracted static secret instead of master_secret? There's a TODO about changes to use of the master_secret here; could you explain this bit please? (I assume this is a work in progress) Are there two finished_secret in the event that the client sends a certificate? The computation of verify_data could probably be moved up to the same section so this is all in the same place. Am I correct in reading that it could be simplified a bit? (e.g. HKDF-Expand-Label(master_secret, finished_label, handshake_hash, L) without the extra HMAC currently defined for verify_data) Thanks, Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] crypto computations & lifetimes clarifications (was: TLS 1.3 - method to request uncached shared secrets)
On Monday, July 20, 2015 01:31:15 pm Hugo Krawczyk wrote: > Your question boils down to: Why is finished_secret derived from SS only > and not from ES? > > First note that the issue only arises in the known_configuration case since > in other cases ES and SS are the same. > For the known_configuration case there are two important reasons > to build on SS and not on ES: > > 1. Only SS can authenticate the handshake as it is the only element to > involve the server's (semi) static private key. > 2. One of the main elements to be authenticated by the server (via the > Finished message) is the ServerKeyShare, thus deriving the key for the > Finished message (i.e. finished_secret) from ES (calculated using > ServerKeyShare) would create a circularity issue in the logic of the > derivation. > > Note that the derivation of application keys (and other key material > remaining after the end of the handshake) do involve both SS and ES, but in > that case involving ES is crucial to achieve forward secrecy. Thanks for the explanation. Using the master secret could work, but adding the ES isn't productive so using the SS directly makes more sense than mixing SS+ES first. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote: > I thought that Brainpool curves weren't removed (even if those aren't > explicitly in), which are random prime curves. > > Also, the security of binary curves seems quite questionable. Brainpool curves aren't in the TLS 1.3 draft, but they're not prohibited either. If there's no strong objection, I'd like to add them to the list, if just to document the current NamedGroup registry. I could add a recommendation to stick to standards track, for those worrying about them. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiating with known_configuration
On Tuesday, July 21, 2015 07:04:14 am Eric Rescorla wrote:
> struct {
>select (Role) {
> case client:
>opaque identifier<0..2^16-1>;
>CipherSuite cipher_suite;// NEW
>Extension extensions<0..2^16-1>; // NEW
>
> case server:
>struct {};
>}
> } KnownConfigurationExtension
>
> The server would just need one configuration for each public key and
> woudldn't need to have any client-specific state. It also has the
> benefit that it makes PSK work with 0-RTT.
>
> Thoughts? Improvements?
A simple suggested improvement: name the fields clearly to indicate what they
are.
e.g.
opaque server_configuration_identifier<0..2^16-1>;
CipherSuite early_data_cipher_suite;
Extension cached_server_extensions<0..2^16-1>;
Use this same ID field name in ServerConfiguration.
Also, why is this ID allowed to be so big? It's extreme overkill now that it's
down to one config per pub key, with nothing client specific. It doesn't need a
string with a 16-bit length; it barely needs a single 16-bit integer.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A la carte handshake negotiation
I've updated the a la carte proposal again with some improvements to readability. I've also added in the ECDHE PSK cipher suites in the current draft, as they are required for this. current WIP text: https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites diff from PR #201: https://github.com/davegarrett/tls13-spec/compare/alertsandcerts...davegarrett:alacarte Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Remove signature algorithm from the cipher suite
On Wednesday, July 22, 2015 10:30:24 am Kyle Rose wrote: > How about removing the RSA/ECDSA from the cipher suite, and making the > SigAlgs extension mandatory for connections requiring authentication? > That halves the number of cipher suites and eliminates an unnecessary > redundancy, while keeping the rest of the cipher suite negotiation > logic intact. This is already a part of the current a la carte proposal that's been under discussion. recent summary of changes: https://www.ietf.org/mail-archive/web/tls/current/msg17156.html current WIP text: https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites diff from PR #201: https://github.com/davegarrett/tls13-spec/compare/alertsandcerts...davegarrett:alacarte Both the supported groups and signature algorithms extensions are mandatory in this proposal, and they are the sole methods to select key exchange and certificates, with the ECDHE_ECDSA prefix being essentially frozen for certificate authenticated cipher suites. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On Wednesday, July 22, 2015 07:36:50 am Martin Thomson wrote: > On 22 July 2015 at 02:29, Yoav Nir wrote: > > PR at > > https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml > > ? > > https://github.com/tlswg/rfc4492bis/pull/6 Could the cipher suite names be officially changed to add the 'E' to them? It'd make things simpler to be consistent. e.g. TLS_ECDH_anon_WITH_AES_128_CBC_SHA => TLS_ECDHE_anon_WITH_AES_128_CBC_SHA Anon is ephemeral by nature, but putting the 'E' in there matches existing notation better. TLS 1.3 will be deprecating all ECDH in favor of ECDHE, so it would be nice to not have to always stick in side notes that ECDH_anon==ECDHE_anon. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4492 ECDH_anon
On Wednesday, July 22, 2015 01:20:52 pm Martin Thomson wrote: > I believe that renaming entries in the IANA registry is possible. Negotiated FFDHE is renaming an extension identifier in the IANA registry, so this is not an entirely new issue. https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] A la carte concerns from IETF 93
Consensus was my current WIP proposal is not viable, for some of the following main reasons: 1) cost/benefit analysis doesn't seem to be worth it 2) backwards compatibility handling 3) some argue harder to implement; others argue easier To start, I'll note that I have not submitted a PR yet. This is all currently just on a WIP branch on GitHub to be easier to discuss specifics on-list. It's based on PR #201, but that's just to make keeping track of things easier. This is less of an issue now that my other PRs were merged (namely the updated cipher suite section). I'll switch to a standalone proposal for the next draft instead of editing the section inline, as it was indicated that would be easier to follow. Not everyone was a party to every discussion on-list about these topics, so a better summary is needed. On to the concerns: 1) The cost/benefit analysis is a very important concern. If you're only analyzing this from a perspective of combinatorial explosion reduction, then I actually agree it's not worth the cost. Here's how I perceive it, currently: benefit: + reduction in combinatorial mess (primarily achieved as we move forward, as back compat still needs to offer some old) + single point of negotiation for (EC)DHE + single point of negotiation for certificates (seemed to be wide agreement to do this regardless of full a la carte) + deprecation of existing DHE suites which risk wanting weak groups depending on server and are an interop hazard due to Java being crap + ECC is always an option, regardless of suite offer/selection + FFDHE doesn't need new suites to be offered by clients not offering DHE AEAD at the moment + missing combinations are no longer an interop failure cost: - change has risks of mistake at various points (implementation, deployment, admin, client config, etc.) - support for TLS 1.2 + 1.3 results in a mix; old suites still need to be offered - risk of confusion due to change in behavior (point #2 above) depends: +/- point #4, depending on implementation (the number of points in this list is not indicative of weight; the first cost could outweigh all benefits, depending on perspective) Additionally mentioned cost: - cannot specify exact combinations; some might not be desirable However, I set this one aside because it's a problem with a full a la carte proposal, but not my current one. All possible combinations of DHE/ECDHE+RSA/DSS/ECDSA/PSK/anon+cipher_hash are already considered valid, and generally have their own suite assignments. I'm not suggesting breaking up cipher_hash. Cert/PSK/anon still have to have separate suites in this system, which prohibits wrong stuff like none_anon (lack of DH from plain PSK + anon). If we ditch suites entirely, as was suggested by others, then this is a risk that comes up. The main difference in my calculus vs. others is that: a) I'm swayed by Tony Arcieri's argument that DHE, as it currently exists, needs to be scrapped. Old Java chokes on it and there is a risk of servers negotiating weak groups when offering it. Deprecating all DHE suites is an interop and security win. FFDHE is still around, but now with only strong groups, whereas without this proposal we go ECC or bust (until something post-quantum is a viable option here). b) ECC isn't separate anymore; it's always expected to be available. We don't have to worry about endpoints actually offering suites that claim support, as it's just a given now. c) Interop failure due to missing suites, regardless of algorithm support, is no longer a risk. It's currently possible to negotiate CBC because the GCM suites offered by the server are combinations not supported by the client, even though GCM is supported. (this does happen in the real world and is too often overlooked in this discussion) 2) Backwards compatibility is pretty straightforward. Here's what Firefox currently offers, minus RC4 & 3DES: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA The current TLS 1.3 draft would only accept the top two as viable (only AEAD). Both my current proposal and the general consensus minimum would pick just the top one and pick certs based on the extension. Note that DHE/FFDHE is available, but only for AES CBC with RSA. The second change here is that my proposal allows DHE with no changes to this list. Yeah, we'd like to move to an ECC only world, but I'm paranoid and want a backup. This gives it effortlessly. This would also permit FFDHE+ECDSA combinations without new suites. All DHE suites could be dropped in the future, in favor of ECDHE only on old TLS but the possibility of FFDHE on new. If you want to keep around FFDHE without this proposal, you ne
[TLS] new error alerts?
Hubert Kairo found quite a few more spots in need of explicit error
designations, which have been amended into PR #201.
https://github.com/tlswg/tls13-spec/pull/201
I just noticed one error in the current draft text that was wrong and added a
fix for that as well. The Server Hello section said that lack of acceptable
group would result in an "insufficient_security" error, which is incorrect.
That error is clearly defined to be for lack of acceptable cipher suite. The
Negotiated Groups section says lack of acceptable group is a
“handshake_failure” error. I changed the text to state the error for suites, as
the other is already noted elsewhere. (this change is now in PR #201) This
brings up a problem, however: there is no distinct error for lack of group
support. The “handshake_failure” is a bit of a catchall, so there's no way for
a client to really know what's wrong if this happens. This is also why I don't
want to change the definition of the "insufficient_security" error. Clients
rely on these being relatively precise in order to show error messages that are
hopefully meaningful enough to get them fixed. As such, I'd like to propose
adding a new error just for this and renaming the old one to focus precisely on
its long defined meaning. While we're at it, a failure of client authentication
doesn't have its own error alert code either.
enum {
handshake_failure(40),
unsupported_cipher_suites(71), /* formerly insufficient_security */
unsupported_dh_groups(72), /* new */
client_authentication_failure(73), /* new */
(255)
} AlertDescription;
Pretty straightforward. Are there any other errors that can't be clearly
identified by the returned code? Debugging shouldn't be guesswork. ;)
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] new error alerts?
On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote:
> Dave Garrett wrote:
> >
> > enum {
> >handshake_failure(40),
> >unsupported_cipher_suites(71), /* formerly insufficient_security */
> >unsupported_dh_groups(72), /* new */
> >client_authentication_failure(73), /* new */
> >(255)
> >} AlertDescription;
>
> I mean I kinda agree that 'insufficent security' is a misleading name,
> but as it has been used for decades in TLS I'm a bit hesitant if it's a
> good idea to change the name now.
If that's really an issue, then it could just be insufficient_security,
insufficient_dh_security, & client_authentication_failure. The name isn't as
important as not producing errors without clear meanings.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] ban more old crap (was: A la carte concerns from IETF 93)
On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote: > vast swaths of web servers are misconfigured; introducing a more complex > mechanism to server configuration when the existing situation is > incomprehensible to many administrators won't help (and even many people that > write the various blog posts about "how to configure SSL [sic] in httpd" > clearly haven't read openssl ciphers(1) man page) We should just get more serious about banning old crap entirely to make dangerous misconfiguration impossible for TLS 1.3+ implementations. Right now, the restrictions section prohibits: RC4, SSL2/3, & EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available How about we stop being fuzzy? I'd like to make it "MUST" use AEAD with all TLS 1.2+ connections, or abort with a fatal error. Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0, or abort with a fatal error. (the wrench in this is plain PSK, which should be restricted to resumption within a short window; IoT people who want to use intentionally weak security can write their own known weak spec) By the way, even IE6 on XP supports DHE. Windows XP, however, appears to be badly configured to only allow it with DSS, because missing combos from the cipher suite nonsense happen. If we actually have to care about IE on XP, we could state an exception that the only non-PFS cipher suite to be permitted on servers for backwards compatibility is TLS_RSA_WITH_3DES_EDE_CBC_SHA. Also add a requirement that all config provided by the admin must be validated to meet the TLS 1.3 requirements and auto-corrected if not, with a warning if there's an issue. This doesn't have to be a mess for admins to sort out. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93)
On Thursday, July 23, 2015 12:00:34 pm Viktor Dukhovni wrote: > On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote: > > Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0, > > or abort with a fatal error. > > Who's going to police the Internet to remove all the legacy services? I'm not proposing a non-PFS diediedie RFC; just that no TLS 1.3+ server should ever be willing to negotiate non-PFS. (again, with very limited possible exceptions) I was probably unclear, but I'm primarily talking about server-side here, as it was a reply to a server-side issue. Clients SHOULD only be negotiating PFS, but I think servers MUST only negotiate PFS. > Exchange 2003 has a broken 3DES implementation. The only working > ciphersuites are RC4-SHA/RC4-MD5. RC4 already got a diediedie RFC. If their 3DES stays broken, and nothing better is available, it's already considered illegitimate to continue using. Also, I don't care. It is not the role of the TLS 2015 WG to work around bugs in abandoned software from 12 years ago. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Thursday, July 23, 2015 01:10:30 pm Eric Rescorla wrote: > On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell > wrote: > > A suggestion - could we remove mention of anything that > > is not a MUST or SHOULD ciphersuite from the TLS1.3 document > > and then have someone write a separate draft that adds a > > column to the registry where we can mark old crap as > > deprecated? > > I'm starting to lean towards this. I don't generally think of TLS 1.3 as a > vehicle > for telling people how to configure use of TLS 1.2, and I think it might be > better > to move all that stuff out. If we've learned one thing from the past year of high-profile vulnerabilities with names and logos, it's that TLS is not really secure if you don't take into account its weakest/oldest feature that's still possible. I don't think any responsible TLS 1.3 spec can afford to not acknowledge this. That said, if all you want to move out are things that aren't MUSTs or SHOULDs, I don't see a problem with that. (with possibly the exception of a "NOT RECOMMENDED" or two, though that's really just a synonym for "SHOULD NOT") What would that actually entail? Or, did you just mean to cut out all non-MUST/SHOULD cipher suites? I also don't see a problem with that. I just updated the list with everything. The full list can go in a separate document if we want to just focus on MUST/SHOULD support ciphers in the spec, proper. Also on the topic of cutting out hunks of text, someone should write up a DSS/DSA removal PR. There's quite a bit of text scattered throughout the spec to handle it that we don't need anymore. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] new error alerts?
On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote: > I mean I kinda agree that 'insufficent security' is a misleading name, > but as it has been used for decades in TLS I'm a bit hesitant if it's a > good idea to change the name now. Alternate bikesheddy response: what about renaming it to "insufficient_cipher_security" and adding a new "insufficient_dh_security"? That keeps the legacy naming, but modifies it to include actual specific meaning, rather than a total replacement. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] new error alerts?
On Thursday, July 23, 2015 03:31:06 pm Aaron Zauner wrote: > Fine with that. Now that I think about it again; I'm also fine with the > original proposal. The thing is 'insufficient security' has a nicer ring > to it than 'unsupported XYZ'. It's wrong, though. If a server rejects a client connection because the server only supports RC4 and the client doesn't, the correct error for the server to return is "insufficient_security". If you invert the meaning, I guess the server has insufficient security, but it's not the same. If we're ok with a complete change, then I'll just go with the "unsupported_X" format as there's already an "unsupported_certificate" and "unsupported_extension". I'll stick a commit for this into my ever growing PR #201 in a bit. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] new error alerts?
On Thursday, July 23, 2015 10:52:59 pm Andrei Popov wrote: > Rather than renaming and otherwise modifying the meaning of the existing > alerts, would it be better to define new, more granular alerts in 1.3? We > can’t ascribe new meanings to alerts generated by the code we’ve shipped in > the past. I'm not proposing changing the meaning of existing alerts. At most, the Negotiated FF-DH draft would need to be updated/fixed. I'm proposing renaming "insufficient_security" to "unsupported_cipher_suites", which is explicitly what it's been for since TLS 1.0. There isn't a specific error defined for lack of a supported group yet. RFC 4492 just says "fatal handshake failure alert". The Negotiated FF-DH draft has "insufficient_security" for unsupported group. _That_ does change the meaning, as previously it was explicitly defined for cipher issues only. What I want is to add a new "unsupported_groups" alert to use instead. (both here and there) The "client_authentication_failure" alert suggestion is to pull that out of the "handshake_failure" catchall. I just want to clarify the existing alert, not reuse it for a related but distinctly different alert, and not lump stuff into a catchall that we can't debug. ;) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] new error alerts?
On Friday, July 24, 2015 01:50:31 am Andrei Popov wrote: > > I'm proposing renaming "insufficient_security" to > > "unsupported_cipher_suites", which is explicitly what it's been for since > > TLS 1.0. > > Not quite. Insufficient_security alert is defined as follows: > " Returned instead of handshake_failure when a negotiation has >failed specifically because the server requires ciphers more >secure than those supported by the client. This message is always >fatal." > > This is a very narrow and specific definition. The server says "I know all > the cipher suites the client advertises, and consider them too weak". By > contrast, unsupported_cipher_suites means something like "I don't have a > cipher suite in common with the client". The latter can happen when the > client's cipher suites are more secure than the server's. Then if we wish to keep this as narrow as written, we can just have a separate one for unsupported with no judgment on strength: insufficient_security(71), // unchanged unsupported_cipher_suites(72), // new unsupported_groups(73), // new client_authentication_failure(74), // new e.g. RC4 gets insufficient_security & Camellia gets unsupported_cipher_suites Sounds good to me, if we prefer this. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Friday, July 24, 2015 06:43:17 am Hubert Kario wrote: > And I completely agree. FREAK and Logjam wouldn't happen at all if we didn't > drag with us stuff that was considered legacy 10 years ago. > > But stuff like "server MUST abort handshake if it sees export grade ciphers > in > Client Hello" (or anything similar) will just get ignored. For a user a bad > connection is better than no connection. One works and the other doesn't, the > details are voodoo witchcraft. To be clear, the wording I have in the PR is not this broad. It only requires aborting if export ciphers were offered by a TLS 1.3+ client, not just any client. The point is to ensure that all TLS 1.3 implementations cut this out and don't regress due to error or exploit. Applying it to everything would, unfortunately, be a mess. In particular, search engine spiders actually have a legitimate reason to have export ciphers actually still enabled. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Friday, July 24, 2015 01:18:41 pm Hubert Kario wrote: > On Friday 24 July 2015 12:57:42 Dave Garrett wrote: > > To be clear, the wording I have in the PR is not this broad. It only > > requires aborting if export ciphers were offered by a TLS 1.3+ client, not > > just any client. > > and how a server can tell that the client is TLS1.3 only and not TLS1.0-up-to- > TLS1.3? TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3 only. A TLS 1.0-1.2 client, or at least one offering that, is what it would not complain about. For the rare case of "legitimate" use of export ciphers, namely spiders, it'll need a fallback attempt with a full set of suites. Export ciphers are not something we should be accounting for allowance of in any protocol we want to claim to be secure. We do have to remember that even _offering_ them is dangerous, even if they're not negotiated. It's dangerous to even _support_ them, even if not offering. Having this in any way presents an unacceptable attack surface for a MitM to try and find a way to confuse implementations into using them. If all implementations were perfect, yeah, this wouldn't be a problem. History has shown this is not the case. :( Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] 0-RTT & resumption
I'm pretty sure some/all of this was likely mentioned elsewhere, but I don't see any discussion on-list. (it was mentioned in part of the IETF 93 recording I watched as this whole topic needing to go to the list, as well) There's also related TODOs in the draft on this topic. Here's a start to this discussion. Basically, there's two modes with similar use-cases in TLS 1.3 now: 0-RTT connections using the known configuration extension & PSK-based session resumption. I don't think their roles are well defined yet. 1) There is no 0-RTT resumption. The point of resumption is to get back into the session quick, but it's arguably slower than not doing it, currently. 0-RTT can do first flight (repeatable) requests: https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.3 but PSK-based resumption needs 1-RTT: https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4 2) There's not yet specifics on what cipher suite to use for PSK-based resumption. I don't see a point in doing PSK-based resumption with anything other than plain PSK, with no PFS (no (EC)DHE). If you're willing to do the extra work for DH, just go straight to normal 0-RTT to get more benefit/flexibility with a similar amount of work. The goal is really to get forward secrecy on the session, not necessarily every single connection within it. (not that it wouldn't be nice) As long as the resumption is within a reasonably short window (e.g. few minutes), not doing another DH is fine. After this window, normal 0-RTT should be the preferred route. 3) Just to state the obvious: If a client is going to do PSK resumption with a non-PFS suite, it needs to offer a non-PFS suite. Even if it's not really going to be negotiated for anything else, I don't really like the feel of this. I think it'd also be cleaner if the offered suites didn't have to change for resumption. One idea would be to rename the groups extension, again, to "supported_key_shares" and mark point 0 (or some other if we want to leave 0) as PSK-resumption, specifically. (_not_ general PSK) A resumption PSK offer could then be listed in the ClientKeyShare like any other, and negotiation of it could side-step the need to pick a new cipher. Mixing it in with regular PSK complicates things a bit and has an expectation of needing to offer a PSK suite with the PSK extension. In this case, it'd just be the previously used suite. 0-RTT becomes a little more straightforward: give both short-term resumption via PSK and mid-term semi-static secret 0-RTT clear expiration dates, then the first flight data is just encrypted using whatever is still valid. Worst case scenario is the server ditched the session early and it falls back to 1-RTT. (double-encrypting early data might work, but would be ugly) This sort of re-separates PSK & resumption a little bit, though the handling is still similar. 4) Related issue: maybe define a generic KeyShare struct (group+key_exchange), simplify the few spots to use these, then allow ServerConfiguration to offer a vector of KeyShares? Alternatively, just have one KeyShare in there and offer a vector of ServerConfiguration in the message so each has an expiration date. If we want the possibility of ServerConfiguration being obtainable through alternate means, then it might help for a server to be able to offer two keys with different curves to make support easier to offer. (e.g. P-256 & Curve25519, as we may be transitioning this way for a bit; could be ECC & PQ of some kind, in the future) This might make constructing a 0-RTT first-connect system a little easier. Not a solid proposal, really; just some discussion on the topic. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Saturday, July 25, 2015 01:18:49 pm Viktor Dukhovni wrote: > I would go further, and say that "prohibiting RC4" in any sense > that is more than prohibiting its use as the final outcome of a > handshake would be a rather counter-productive strategy. > > Servers and clients are strongly encouraged to not choose it, but > to reject connections from peers that offer it for interoperability > with others would just create a mess that would be operationally > challenging. RC4 is dying, just let it fade away into insignificance. I agree. The current draft language of not offering or negotiating RC4 is fine, as-is. My proposal of stopping tolerance of garbage suite offers is just for <112-bit junk. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote: > > What sort of usecase you have in mind for this? > > This is to support a fairly common website design where the landing page does > not require client auth, but subsequent request to a protected resource > triggers client authentication within an existing TLS connection. > In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there is no > renegotiation, so we need an alternative solution if we want to support these > existing sites over TLS1.3. This is just an idea, but what about just allowing a renegotiation-like mechanism via 0-RTT with PSK resumption to be triggered on a TLS alert or HTTP response code? The rough idea would be like this: 1) client connects to server and fetches public resources 2) client requests restricted resource; server sends auth required response (TLS alert or HTTP code) 3) client creates a replacement connection using PSK-based resumption and early data in the first flight for the request along with the client cert. There's a 1 roundtrip cost in there for a new TCP connection, which could possibly be optimized away by using TCP fast open. This general concept is relatively simple in comparison to doing something mid-connection. Instead of attempting to renegotiate on an existing connection, just make creation of resumed connections cheap enough to start over with client auth in the handshake from the start. It's a very rough idea, but I'm wondering if it sounds like something worth discussing. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 comments
On Monday, August 17, 2015 06:22:04 am Yaron Sheffer wrote: > The record length field is limited by encrypted-length+2048. Shouldn't it be > 1024? - "Each AEAD cipher MUST NOT produce an expansion of greater than 1024 > bytes". See: https://github.com/tlswg/tls13-spec/issues/55 > Handshake_failure alert seems to be synonymous with insufficient_security > (and Sec. 6.2.1 proves it...). Can we clarify the difference, or deprecate > one of them? See: https://github.com/tlswg/tls13-spec/pull/201/commits A PR for the typos would be appreciated. I'd suggest having the typos in a separate PR from any other proposed changes. Dave PS I recommend against citing sections by number. The numbers can change; the sections can change completely. Cite by draft number & section, or preferably via a link to a section in a page. Also note that there are a few different things that can be considered the "latest" draft, so always specify which one to be clear. (e.g. numbered draft, GitHub current draft, PR drafts, WIP branch drafts, etc.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] padding
On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote: > On 17 May 2015 at 14:32, Dave Garrett wrote: > > Is it really necessary to have a separate application_data_padded content > > type? It'd be simpler to just keep using existing types but amend it with a > > padding field and require it always be used at minimum to pad up to the > > nearest multiple of N-bytes. (something low for the default) Additional > > padding would be optional, but all data would get some minimum. > > That was the first proposal, but the extra bytes on every message for > people who weren't using padding were deemed to be prohibitive. Wouldn't it be simpler to just have an optional padding vector that exists only if padding is negotiated? (we already have one optional field with extensions in the hello messages) A simple method to negotiate would be to add a new HandshakeType with a couple flags, one to indicate that the endpoint will be sending padded messages and another to indicate that it's willing to receive padded messages. Endpoints could declare padding with this message and use it until its peer sends a message requesting otherwise. This sort of scenario would have the additional benefit of not stating the existence of padding in the clear. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] padding
On Saturday, August 22, 2015 03:36:21 pm Russ Housley wrote: > > On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote: > >> On 17 May 2015 at 14:32, Dave Garrett wrote: > >>> Is it really necessary to have a separate application_data_padded content > >>> type? It'd be simpler to just keep using existing types but amend it with > >>> a padding field and require it always be used at minimum to pad up to the > >>> nearest multiple of N-bytes. (something low for the default) Additional > >>> padding would be optional, but all data would get some minimum. > >> > >> That was the first proposal, but the extra bytes on every message for > >> people who weren't using padding were deemed to be prohibitive. > > > > Wouldn't it be simpler to just have an optional padding vector that exists > > only if padding is negotiated? (we already have one optional field with > > extensions in the hello messages) > > > > A simple method to negotiate would be to add a new HandshakeType with a > > couple flags, one to indicate that the endpoint will be sending padded > > messages and another to indicate that it's willing to receive padded > > messages. Endpoints could declare padding with this message and use it > > until its peer sends a message requesting otherwise. This sort of scenario > > would have the additional benefit of not stating the existence of padding > > in the clear. > > I like the idea that the presence or absence of padding in the ciphertext is > hidden in your proposal. Is there really an need to toggle it on and off? Toggling solves the undesired bandwidth use concern stated by Tom by making it fully optional on both sides. The even simpler route of just having to check if there's bytes in the encrypted fragment other than the payload would avoid a little bit of complexity, but with no way for an endpoint to say no to increased bandwidth usage that it doesn't want to or can't handle. Given this constraint, I'd favor either easily toggleable or always-on, rather than a middle-ground where implementations won't know what they're going to get and can't do anything about it. A footnote: Negotiating via an extension is probably not a good idea because client extensions will generally be in the clear. That's why I suggest a simple message instead. (there's no need to pad the cleartext hello, so it's fine to wait until record protection is available) Note that I don't think allowing this to be decided after the handshake is a good idea. A more generalized way to handle throttling padding would be to set a low default and require each endpoint to send a message with a different value, in max bytes per record (or second, or both) of padding permitted, in order to use a different amount. Each endpoint could easily arbitrarily throttle its downstream padding bandwidth independently, if need be. I'm curious as to how much of a range would actually be useful, though. For actually good protection, you'd really want to pick a stable bandwidth and essentially hold it; keep up/download rates constant or following some consistent pattern with a combination of possibly throttled data and padding such that the data length and time is completely protected and the stream is 100% opaque to an observer. I wouldn't expect this to be all that popular, though, as it would be a bandwidth hog in many cases. A middle-ground might involve also specifying a max bytes allowed in between data bursts to hide the peaks, but now we're getting more complicated than I think we want here if we go any further. (and beyond what I know anything about) The current proposal says that padding algorithms are outside of the scope here, but I think adding this as a built-in feature without coming up with some easily usable default (even if not particularly advanced) is a mistake that will cause this feature to be largely unused. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Headerless records (was: padding)
The topic of encrypting the content type came up again, and a core WG charter
goal is to encrypt as much as possible. To this end, I suggest we consider
going all the way in this area: headerless records. Each protected record would
contain nothing but an aead-ciphered struct with the bare minimum it needs,
namely ContentType & content, plus maybe padding. Nothing else is really
needed. The only thing that needs to know anything here is the peer with the
key.
struct {
aead-ciphered struct {
ContentType type;
uint16 length = TLSPlaintext.length;
opaque content[TLSPlaintext.length];
opaque padding[padding_length];
};
} TLSCiphertext;
Arbitrary padding can be added after the content, up to the total record
maximum size. If we even wanted to ditch the length field, we could do:
struct {
aead-ciphered struct {
if (padding_allowed) {
opaque padding<0..(2^14+256-TLSPlaintext.length)>;
}
ContentType type;
opaque content[TLSPlaintext.length];
};
} TLSCiphertext;
In which case content is just the remainder of the record after the type.
(without the explicit length field, padding needs to come first so it can have
its length in its vector first)
Cleartext records would of course be unchanged, as they need to stay as-is for
backwards compatibility.
With an encrypted record format like one of the above, everything after the
handshake is opaque and potentially padded.
The additional data fed to the AEAD cipher is just the sequence number at this
point. The version can easily be mixed into the keying material by adding it to
the HKDF label, and then we don't need to re-verify it after the fact if they
key depends on it.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus on PR 169 - relax certificate list requirements
On Wednesday, August 26, 2015 05:11:01 pm Joseph Salowey wrote: > It looks like we have good consensus on PR 169 to relax certificate list > ordering requirements. I had one question on the revised text. I'm > unclear on the final clause in this section: > > "Because certificate validation requires that trust anchors be distributed > independently, a self-signed certificate that specifies a trust anchor MAY > be omitted from the chain, provided that supported peers are known to > possess any omitted certificates they may require." > > I just want to make sure there isn't the intention of omitting certificates > that are not seif-signed. Well, technically anything can be omitted; it just won't validate. :p I'm not opposed to tweaking the wording here, but I don't really see it as a problem. If someone does, though, that's reason enough for me to agree to changing it. Simplest change is: "any omitted certificates they may require" -> "it" \/ "Because certificate validation requires that trust anchors be distributed independently, a self-signed certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess it." Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote:
> I've been looking at the latest TLS 1.3 spec and there are a lot of
> MUSTs that are completely toothless. To pick on a recent changeset:
>
> > The signature algorithm and hash algorithm MUST be a pair offered in the
> "signature_algorithms" extension (see {{signature-algorithms}}).
Some changes to this are now in this PR:
https://github.com/tlswg/tls13-spec/pull/231/files
(language based on list discussion)
> > All implementations MUST use the "signature_algorithms" extension when
> offering and negotiating certificate authenticated cipher suites.
Actually, I did get a strict requirement in there for that one:
https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-algorithms
> All clients MUST send a valid "signature_algorithms" extension in their
> ClientHello when offering certificate authenticated cipher suites. Servers
> receiving a TLS 1.3 ClientHello offering certificate authenticated cipher
> suites without this extension MUST send a "missing_extension" alert message
> and close the connection.
I think it warrants repeating in the MTI section as well.
> > All implementations MUST use the "supported_groups" extension when
> offering and negotiating DHE or ECDHE cipher suites.
My initial draft had similar language, however ekr says the WG doesn't have
consensus to be more strict. I would like to consider all of these extensions
as mandatory to send, and malformed if not present when offering/negotiating
any applicable cipher suites:
signature_algorithms, supported_groups, client_key_share, pre_shared_key,
server_name (though, I'm fine with a SHOULD error on lack of SNI when
applicable)
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote: > My problem is precisely the conflation of offering with negotiating. The way > that > many stacks work (for instance NSS) is that they negotiate the cipher suite > *first* and then they check for the presence or absence of the relevant > extensions. > It's not clear to me that it's an improvement to require them to check for > error > conditions that are not otherwise relevant. I'm not fundamentally opposed to having a hard requirement of an error check on negotiation, and basically a soft expectation on mere offering (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That said, categorizing the cipher suites and just doing a quick check for which categories are there and what extensions came with it is not a very complicated requirement. I'm philosophically in the "do it right or explode so it can be found and fixed immediately" camp when it comes to very clear requirements like this, but I'm aware that this is sadly not always the dominant thought process. :| Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] MUST or what?
PR to put this into writing: https://github.com/tlswg/tls13-spec/pull/232 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
On Friday, August 28, 2015 11:08:35 am Salz, Rich wrote: > Having discussions through github is a really bad idea. You're right. I posted a stupidly long side-note in there. I intended to bring it to the list too, which I'll do now. On Friday, August 28, 2015 10:49:33 am Viktor Dukhovni wrote: > It seems that with TLS 1.3 the client MUST send SNI, presumably in > the clear. Typically there's not much else of interest in the > server certificate to hide. I don't see a realistic way to hide > the server identity even from passive wiretap via TLS. Currently, we're at implementations MUST support (not necessarily send) SNI, servers MAY require it, and servers SHOULD error on such a failed requirement. This doesn't change the status quo much. If servers don't require it, you don't need to send it. HTTP/2 has its own SNI requirement, though, so lots of TLS will be moving in that direction. The idea I had the other day is that we can technically do SNI encryption with the current TLS 1.3 draft, as-is. All that needs to really be done is stick it in a 0-RTT EncryptedExtensions, preferably only when the server specifies that it is allowed via adding a flag to server config. This would require the actual server share the 0-RTT DH key across the virtual servers it's picking via SNI, so early data probably should be off in this instance for many use-cases. The simplest route that would allow for encrypted SNI with 0-RTT application data allowed would be to just add a second long-term DH key to the server config for SNI (and an option for servers to have one do both if they don't need two). Seeing as this would still need to be opt-in via a flag in the config, we could use the same extension ID and just encrypt it using the second key. Servers that provide an SNI key get encrypted; others get clear or none. If we can also get a way to distribute server config out-of-band, this would even allow initial-connection SNI encryption. I don't think encrypted SNI to servers without any prior information is really that viable, and that's been said before by others on this list. Now, with that said, you could just create a way for any client to ask a server for its config without any attempt to connect right away, in which case it can follow up with encrypted SNI at the cost of that 1-RTT (e.g. the QUIC way of doing things). Even if we allow ServerConfiguration to be optional normally, we could add this config request mode and make support for that mandatory (though, potentially with short-lived keys). This route would still require some prior information about this server: knowledge that it could request a key for SNI at all without just getting rejected. Doing so without that would require a multiple attempt check of some kind that's probably a bad idea. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
On Friday, August 28, 2015 12:33:31 pm Salz, Rich wrote: > > And how often will the same client visit multiple servers at the same > > transport address? > > Anyone who visits sites hosted by a CDN. And, I suspect, many large portals. How's it done with IPv6, generally? Are there setups where everyone is sharing a v6 IP? We could eventually get to the point where a reverse DNS lookup is all that's needed for everyone if things were set up smartly. Probably a better setup for things to work, but worse for passive surveillance. (though, IPv6 could eventually let clients randomize their IP frequently, which helps some things; getting off-topic here, though) > > I don't really see this as viable or worth the effort. > > Agree. I agree that it's a lot of effort for relatively little gain. I might be worth considering, but if the consensus is that TLS just isn't designed to do this easily enough to be worth it, then I don't really dispute a decision to just drop the concept. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecate DH_anon in favor of raw public keys?
I actually had this in my old a la carte proposal. Here's the relevant section posted separately, unedited, except for keeping the current list of RFCs with anon that weren't in that proposal: https://github.com/tlswg/tls13-spec/compare/master...davegarrett:unauthenticated Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Friday, August 28, 2015 04:21:53 pm Hanno Böck wrote: > On Fri, 28 Aug 2015 19:17:39 + > "Dang, Quynh" wrote: > > I don't see a convincing reason to remove support of DSA in TLS 1.3. > > The reason is avoiding feature bloat. I think it makes a lot of sense > to question the support of features nobody uses. At minimum, it's almost certainly getting cut from the TLS 1.3 specification document. It's obsolete, even by DSS standards, and either needs significant updating (e.g. use SHA-2) or dropping. The question will likely be whether it should be considered no longer acceptable or something which is permitted, just rarely supported and described in another document. I'd rather just declare it obsolete and no longer permitted to avoid the attack surface and complexity, and I get an impression that this is a common opinion in the WG. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Friday, August 28, 2015 08:41:23 pm Jacob Appelbaum wrote: > What do you suggest for the construction of the k value in DSA? https://tools.ietf.org/html/rfc6979#section-3.2 ? Also, we still have ECDSA, so the 'k' issue isn't going away. Should we cite this RFC? Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Monday, August 31, 2015 08:43:16 am Hanno Böck wrote: > If you can tell us > a) who is using DSA > b) why they think this has an advantage > we can have a useful discussion. Not to mention: c) why they aren't switching to ECDSA Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Tuesday, September 01, 2015 11:24:59 am Jeffrey Walton wrote: > Regarding "who would actually use it": folks in US Federal (and those > doing business in US Federal) don't have the choices that others have. They, however, obviously do have the choice of switching from DSA to ECDSA, so that argument doesn't make much sense here. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wednesday, September 16, 2015 07:23:34 pm Nico Williams wrote: > On Wed, Sep 16, 2015 at 07:07:31PM -0400, Dave Garrett wrote: > > This appears to just be a miscommunication. > > It is not. > > > The current poll is to remove anon ciphers in favor of raw public > > keys. We're not considering removing raw public keys, as far as I > > know, and I think most of us would be against that. > > Once more, with feeling. I would oppose the current proposal if there > was to be a follow-on proposal to remove raw public keys, which I > wouldn't have even though plausible but for Brian's intimating that he'd > be fine with removing raw public keys. Otherwise I would be neutral as > to removing anon ciphersuites. > > I would also be neutral as to removing raw public keys if anon > ciphersuites are to remain. > > Whichever one is removed, I shall oppose the removal of the other. > > I.e., these two features are interrelated. It is difficult to consider > the removal of one without considering the possible removal of the > other. > > I leave it at that. Yes, I agree with this, and I'm saying that I think that we're all on the same page here. Brian made a point to explicitly not endorse raw keys, but looking back through the messages today, I don't see anyone actually propose removing them. Thus, I said this is likely to be a miscommunication. That's all. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Thursday, September 17, 2015 05:46:39 pm Brian Smith wrote: > Let's ask the browser vendors: > > Browser vendors, if web servers were to stop sending alerts during > handshake failures, would you start doing version fallback when a > connection is closed? Well, what else would clients do instead? The answer is an unambiguous yes. There's no way to tell a microwave oven killing the WiFi and a legitimate handshake failure apart if no information is sent back. Implementors will always assume it's possible to retry, and we know from history that this will involve an unsafe fallback dance. > > I'd rather keep them than remove them, but I'd be OK with clients never > > sending them. I'm OK with fata alerts being SHOULD send. > > I suggest that, at most, implementations SHOULD NOT send them. IMO it would > be better to remove the alert mechanism altogether in TLS 1.3. > > Most people that are arguing for retaining the alert requirements seem to > be concerned about alerts sent from the server to the client. Does anybody > think it is important to require clients to ever send alerts other than > close_notify? There's also user_canceled and cert errors when doing client authentication. The idea of restricting what alerts clients, specifically, should send is not necessarily something I'd object to, though I don't think it's useful. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Thursday, September 17, 2015 06:00:05 pm Brian Smith wrote: > There's no evidence that the presence or absence of an alert when a > connection is closed makes any positive difference in the security of any > non-secure fallback mechanism. Keep in mind that the alerts during the > handshake are NOT authenticated, and the TLS threat models thus assumes > that the attacker can remove or alter them. The whole handshake is retroactively authenticated upon completion. Just because an attacker can muck up the attempt to connect, doesn't mean all hope is lost. The primary benefit with the version alert, specifically, is that it allows a client to at least have a clue as to what to attempt. Without alert: client tries server stares blankly into the void and/or drops abruptly now, what does the client do? try again as-is, or try again with old stuff? With alert: client tries if server responds with an alert, react to it if not, try again until there's a response; give up eventually Sure, a MitM could try to downgrade by injecting an unauthenticated alert into the mix, but the handshake will fail once that is authenticated at the end. Just as the obvious footnote: it's impossible to make any of this resistant to an attacker killing the connection. Just assume that's always possible, at minimum with wirecutters. The goal is security or bust. Alerts give clients the confidence to actually bust when they have to. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Friday, September 18, 2015 04:24:33 pm Brian Smith wrote: > [...] unless a terrible mistake is made [...] We're designing a security protocol to be used globally. We should be assuming that not only will we have at least one terrible mistake, but also that there's at least a few more that have already been made that we haven't found yet, but will still need to handle. Again, this is a 20 year old mess of a protocol; no development can stem from any premise that expects no flaws. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Saturday, September 19, 2015 04:06:37 pm Salz, Rich wrote: > On Friday, September 18, 2015 04:25:39 pm Julien ÉLIE wrote: > > The concern will be when TLS 1.2 is declared "flawed". Maybe one day it > > will > > be considered insecure; and then, compliant TLS implementations won't be > > able to use compression. That facility will then be lost. > > Yes. > > It is widely recognized that in many cases, TLS-level compression is flawed > (for example NNTP authinfo?). TLS 1.3 does not have it. So NNTP that needs > compression can continue to use TLS 1.2, and if TLS 1.2 is "flawed" things > can change. Contrary to its name, TLS is not a transport protocol. It's a security protocol, and compression is not a security feature. (though, when combined with padding, I could see how it could be useful) It didn't belong in the spec like it was, even if it worked safely. It might be doable in a TLS extension, but I don't think this is a great idea. Application protocols can handle compression better and more safely, as they can actually know what they're doing and how to properly compress it. Even if TLS compression could be fixed, the old insecure junk doesn't magically go away. It needs to be treated as ruined forever, just to be safe, as far as I'm concerned. If you need compression, I wouldn't recommend relying on it here. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] encrypted content type and padding
On Monday, September 21, 2015 03:02:47 am Daniel Kahn Gillmor wrote: > encrypted content type: > --- > > https://github.com/tlswg/tls13-spec/pull/51 Basing the padding PR(s) on top of this might be a good idea, seeing as it's desired to do this correctly. One thought about doing this with a separate record type, though. It might be better to generalize it by reserving the top bit in the type as a padding flag, thus allowing padding variants of all other types. Record type values would just be the unpadded value plus 128. Implementations could check for padding by simply ANDing a mask to check for the flag. The remaining 7 bits is plenty for the record types field. This could be used for the handshake messages instead of adding a separate handshake padding message. No special type value registration would be needed to add any future padded types. > i personally prefer PR #249 because it is more inline with the > traditional layout of TLS data elements, and lacks additional risk of > timing differences. Its main downside is its inability to pad by > anything less than two octets, which slightly complicates calculations > of how much to pad when padding algorithmically. I agree. Simpler is probably better here. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Tuesday, September 22, 2015 02:16:47 pm Julien ÉLIE wrote: > Regarding vulnerable protocols, clients (and/or servers) could very well > disable compression in TLS. And either never use compression or > implement their own compression, according to their needs. > It is what happened with BEAST: Firefox and Chrome disabled TLS > compression. No sane security protocol should allow any mode which is known to be insecure under its common use-case. TLS 1.2 is technically configurable in a secure manner, but hardly anyone does so correctly. With TLS 1.3, we need to get rid of all of the insecure modes so all configurations are secure (at least to start). Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] '15 TLS Fall Interim Minutes
Thanks. What sort of errors are we trying to avoid by making sure implementations have to check for zeroed padding? Are we really worried some sloppy implementation is going to leave it uninitialized in a memory-unsafe language and just encrypt an arbitrary block of memory? This was mentioned at some point, and sounds really stupid, but planning for the stupid is probably a good idea. Dave On Tuesday, September 22, 2015 09:18:53 pm Eric Rescorla wrote: > "Versions of TLS prior to 1.3 had limited support for padding. This padding > scheme was selected because it allows padding of any encrypted TLS record > by an arbitrary size (from zero up to TLS record size limits) without > introducing new content types. The design also enforces all-zero padding > octets, which allows for quick detection of padding errors. > " > > On Tue, Sep 22, 2015 at 4:45 PM, Dave Garrett > wrote: > > > On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote: > > > I’ve gone ahead and posted the minutes/list of decisions to: > > > > > > > > https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 > > > > That has this: > > > > > For padding, we reached a very rough consensus to start with the content > > type followed by all zeros (insert reasons why) over the explicit length > > option (insert reasons why). DKG to propose a PR that we'll then fight out > > on the list. See PR #253. > > > > The "reasons why" that were discussed were not inserted. ;) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Obscure ciphers in TLS 1.3
On Wednesday, September 23, 2015 07:40:13 pm Salz, Rich wrote: > Do folks know that we did decide on the MTI list already, and that it's a > matter of ekr updating the draft? (It was decided at a PREVIOUS interim, it > just fell through the cracks.) The MTI list and the larger list of what can/should be supported at all are separate discussions. > And also, even if not, TLS 1.3 is only doing AEAD ciphers. > > The registry isn't going to get purged, but all but two will not be allowed > in 1.3. Let's just wait on this thread a bit. There are AEAD versions of ARIA and Camellia. These GCM suites are currently listed in the available Cipher Suites list in the draft. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
On Friday, September 25, 2015 01:10:37 pm Martin Rex wrote: > Because it is not necessarily immediately obvious, you will need > padding also for the Server Certificate handshake messages. > And, because the key exchange is side-effected by properties of > the Server Certificate, you may additionally need padding for the > ServerKeyExchange and ClientKeyExchange handshake messages, so > that the protocol doesn't leak of one of the service uses > an RSA certificate and the other uses an ECDSA (or EdDSA) certificate. This sounds like a good argument to come up with a default padding scheme for all handshake messages for even clients that don't use application data padding. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] '15 TLS Fall Interim Minutes
On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote: > I’ve gone ahead and posted the minutes/list of decisions to: > > https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 Issue #185 has the "discuss-seattle" tag on it, but I don't see mention of it in the minutes. (it's a suggestion from Karthik to generate a new client random on retry) Did this get discussed? https://github.com/tlswg/tls13-spec/issues/185 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Sunday, October 04, 2015 01:58:09 pm Jeffrey Walton wrote: > Is that necessarily true? It should be apparent by now that the dominant opinion is that compression in TLS is not worth the risk and not worth the time to attempt to deal with here. Whether or not a generic compression algorithm could theoretically be made safe is irrelevant at this point. It's a known-dangerous attack surface that we don't want the risk of. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Sunday, October 04, 2015 02:09:49 pm Tony Arcieri wrote: > If someone has produced a secure system for "compression side-channel > resistant encryption", I haven't seen it. I can think of a way to do this, but the people who want compression badly probably won't like it due to the need to pad heavily. 1) Pick a fixed bandwidth 2) Compress & encrypt the stream 3) Send the compressed stream at a rate blocked to the cap 4) Whenever below the cap, pad the stream to the cap Maintain a fixed transmission of data per unit time and there's no way to tell the size of anything (even if delivery doesn't match the rate). However, this relies on being able to pick a usable fixed bandwidth (in each direction). The bandwidth cap size and length of transmission times still gives quite a bit of info, e.g. 1GB vs 1KB total is quite telling, but that's true without compression. With a good compression algorithm, the above could probably produce an overall more efficient stream rather easily for many things. If your idea of compression is to keep using DEFLATE forever, however, you should probably just reevaluate what you're doing. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Sunday, October 04, 2015 02:48:19 pm Jeffrey Walton wrote: > If I am reading things correctly: the group has effectively > encountered a security problem, deemed it to be too hard for them, and > then pushed it into another layer where folks are even less equipped > to deal with it. Is that correct? > > I might be missing something, but I don't believe the "problems > created by compression" have gone away. Rather, they have been moved > around so the risk remains. The underlying problem still exists > because the group responsible for providing those security services > have not addressed them. TLS & SPDY + HTTP compression was broken due to CRIME. The fix was to disable it, and then HTTP/2 introduced HPACK to compress headers safely. Yes, the security issue has been moved around, but to a place that can actually fix it properly. There is nothing TLS could do to implement a fix like HPACK here. I don't claim this is the only way to fix this problem, but it is a straightforward one and the one that is being done. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Sunday, October 04, 2015 03:00:33 pm Tony Arcieri wrote: > On Sun, Oct 4, 2015 at 11:50 AM, Dave Garrett > wrote: > > I can think of a way to do this, but the people who want compression badly > > probably won't like it due to the need to pad heavily. > > > > 1) Pick a fixed bandwidth > > 2) Compress & encrypt the stream > > 3) Send the compressed stream at a rate blocked to the cap > > 4) Whenever below the cap, pad the stream to the cap > > > > Maintain a fixed transmission of data per unit time and there's no way to > > tell the size of anything (even if delivery doesn't match the rate). > > This sounds like Constant Bitrate (CBR) compression, which works for > encrypted media (e.g. encrypted voice and video), but probably isn't > particularly useful outside the realm of realtime media. It was a solution > that seems to work for attacks that could e.g. transcribe encrypted phone > calls by studying patterns in Variable Bitrate (VBR) compression on speech. > > Typically compression is used to lower the overall size of data, working on > a wide class of inputs. In the perceptual coding case the class of inputs > is constrained, and the goal is to keep the data rate constant, not > optimally small. Yep. You could do this in bursts with different caps each time to get it to work with bursty things like HTTP & other general data transfer protocols. Without a really good modern compression algorithm, though, it isn't that appealing. Once these caveats and tweaks start getting added to the simple concept, it starts treading into the territory that is better handled by the application protocol that actually *knows what it's sending*. This seems to be the logical wall we keep hitting, which is why TLS doesn't seem like the place to do this. Maybe some new transport protocol could be fed information to tell it how to handle compression safely, but TLS is not a transport protocol nor a young one that can be fundamentally changed to accommodate everything. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Wednesday, October 07, 2015 03:51:57 pm Martin Rex wrote: > However, it is RECOMMENDED > that implementations which support compression provide a configuration > option allowing consumers to disable the use of compression in TLS. Risky features like compression should be off by default. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On Friday, October 09, 2015 12:49:02 pm Viktor Dukhovni wrote: > I think this is "too clever" (a "hack" not a design) and offers Every fix to an issue in this 20 year old protocol will be a hack. > incomplete protection (does nothing to protect RSA key transport). Better than none, for a very low cost. > So I do not support adoption of this proposal. > > If new attacks against TLS 1.0--1.2 emerge that enable MITM via > version downgrade combined with use of weaker algorithms, then > we'll just have to prohibit those weaker algorithms in TLS 1.3 > servers (and possibly also clients). Those changes are harder to make than they should be, unless we want to do that now. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On Friday, October 09, 2015 04:38:00 pm Viktor Dukhovni wrote:
> So even 2^{-48} is perhaps not quite low enough.
Going to a full 64-bit looks like a good idea to me. The loss of those 4 bytes
of entropy for old versions isn't likely to matter at all, though, please
correct me if someone thinks otherwise.
On a related note, I think it might be a good idea to add a note somewhere
stating that TLS 1.3 now only uses the hello random values indirectly, but
they're still used via the session hash.
On a tangential note, if anyone sees the need to increase the entropy
introduced in the hellos, a supplemental random extension sent by both
endpoints would be trivial to create with the current design. (questioning the
size of the randoms here is an explicit question in the current TLS WG charter,
as is the topic of additional downgrade mechanisms)
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
On Saturday, October 10, 2015 04:28:28 pm Ilari Liusvaara wrote: > On Sat, Oct 10, 2015 at 07:44:04PM +0200, Eric Rescorla wrote: > > To be clear, the only thing that's allowed is SHA-1 in *certificates*. > > It's forbidden in CertificateVerify. > > Isn't using it in certificates precisely more dangeous than using it in > CertificateVerify (especially with TLS 1.3)? > > (Not that using it in CertificateVerify is a good idea). You can take all the time you need to forge something in a certificate chain (before expiry time), but to forge CertificateVerify you'd need to do it on the fly. Really dangerous vs. somewhat dangerous doesn't matter much here, though. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
On Saturday, October 10, 2015 04:59:09 pm Viktor Dukhovni wrote: > So long as SHA-1 self-signatures are still tolerated in root or > self-signed end-entity certificates, I have no objection to TLS > 1.3 specifying that a certificate signed with SHA-1 is not trusted > even when issued by a trusted issuer. > > However, we *must* be careful about what obligations we impose on > a client or server that encounters a certificate chain in which > some certificate which is not self-signed uses a SHA-1 signature. > It would be a big mistake to mandate fatal or even warning alerts > or closing the connection. Rather, the required outcome is that > the chain is simply not trusted. > > Whether *that* in turn leads to a connection termination depends > on whether verification is required. Opportunistic clients, or > servers that solicit optional client certificates need to be able > to continue despite the untrusted chain, and do what they do in > the absence of a peer certificate or when the peer certificate has > accceptable signatures, and and yet is still untrusted (or peername > does not match, ...). > > So if the draft language for 1.3 essentially only prohibits *trusting* > SHA-1, but does not prohibit the *presence* of SHA-1 in the peer's > chain, I think that should be fine. > > I don't want to see client's or servers hanging up just because a > peer presents a SHA-1 chain that would have been simply ignored > had it been SHA2-256 instead. Yes, to all points above. I feel like self-signed certs should have to use SHA-256 too, but mandating that doesn't get us that much. The current PR is a bit too general; will need revision to handle all cases. I'll of course change it to accommodate concerns that come up in discussion here. Note that opportunistic encryption is weird and getting the whole document to be perfect for it might not be entirely doable, as OE needs to tolerate more fuzziness than the main spec should allow. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
On Saturday, October 10, 2015 05:19:30 pm Viktor Dukhovni wrote: > On Sat, Oct 10, 2015 at 05:11:56PM -0400, Dave Garrett wrote: > > Note that opportunistic encryption is weird and getting > > the whole document to be perfect for it might not be entirely doable, as > > OE needs to tolerate more fuzziness than the main spec should allow. > > Unfortunately requirements in the base TLS document end up "set in > stone" in software implementations, and then break opportunistic > TLS in ways application software can't work around. I do agree with rewording the text in question to deal with this better, but honestly, OE & AE are directly opposed concepts. I'd much rather write almost everything assuming the goal is properly authenticated encryption, and have a separate section dedicated to opportunistic encryption stating that its implementation requires ignoring many of the hard requirements TLS has with regard to authentication. Trying to subtlety allow for AE & OE in all the same text might give us a more fragile specification where accidentally screwing up authentication is easier. OE can be useful, but it's the exception, not the rule; giving AE too much wiggle-room could be dangerous. (when it's explicitly requested, e.g. TOFU with raw public keys, that's a different discussion) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
On Saturday, October 10, 2015 10:35:16 pm Viktor Dukhovni wrote: > This is not difficult, it just requires not forgetting that there's > more than one way to do (or not do) authentication, and that the > TLS protocol needs to remain largely agnostic of the authentication > model. Just deliver the available credentials to the peer, and > let the peer decide what to do. It's the "or not do" that's the issue, not the other ways to do authentication that I'm concerned about. As I said, it looks like we can word this properly in a way that works for everyone. I just feel like the best way to cover the OE case fully is to address it in a separate section, explicitly, rather than (just) tweak wording to accommodate it. Even TOFU is more straightforward than OE, because at least with that it always follows basically the same pattern. OE requires you take what would normally be a blatant catastrophic error, but wave a wand and say it's OK for this separate use case. That may be true, but that doesn't make it any less of a blatant catastrophic error when that's not the case. I'm worried about having these not be completely distinct for the same reason you don't put a self-destruct button next to a light switch, no matter how well labeled. ;) Also, I want the spec to anticipate some peers being incredibly stupid and avoid making it easy to mess things up. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] banning SHA-1 in TLS 1.3, a new attempt
On Sunday, October 11, 2015 08:00:45 pm Viktor Dukhovni wrote: > There's no reason for pessimism Sorry, I have to laugh a bit here. :p > we're not trying to deprecated deployed > functionality, there is no TLS 1.3 deployed base. Due to the fact that the vast majority of TLS implementations that will be used are going to be existing ones, upgraded to support TLS 1.3, yes we are deprecating deployed functionality for that implementation as well as their users. > > Prohibiting TLS 1.3 implementations from using SHA1 certs does not break > > OE. > > It does when the SHA-1 leaf certificate is pinned, and/or the server > has nothing else to send, and its clients rightly don't care. In the second case, a correct course of action for the server would be to send an incomplete or outright empty certificate_list fallback, in which case the clients that don't care will be fine with it. Pinning a SHA1 end-entiy (leaf) cert rather than an intermediate just seems like a bad idea that you can't expect to work forever. In cases where the server can't handle lack of SHA1, then my response is to fix that before upgrading TLS. > > My goal is to have fewer systems using SHA1 within a reasonable timeframe. > > That happens automatically in the minimal version of the PR. We're both trying to predict possible futures with different thought processes. I'm concerned that the simpler course is too slow, _not_ because we need to rush to get rid of SHA1 certs ASAP, but because going slower requires keeping SHA-1 around in implementations in the interim. Even requiring settings and code for an algorithm at all poses an attack surface by itself (we had attacks on supposedly disabled features over the past year). Every known vulnerable feature is one which we have to be wary of getting re-enabled or left on accidentally. I consider this risk to be high enough to not rely on delegation to another layer; you think that delegation cannot be changed without excessive interop risk. I'll post a follow-up question to the WG (with a changed title, as our discussion here got long) with the options phrased as a question with 3 main choices (including the option of doing nothing new). If there's no support for a full drop in SHA-1 support under the new version, then there won't be a point in pushing for it further, unless there's yet another SHA-1 revelation in the near future. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The SHA-1 Options (was: banning SHA-1 in TLS 1.3, a new attempt)
I'd like to get a sense of what the WG is willing to consider with regard to SHA-1, rather than only Viktor and myself discussing this. Basically, I see 3 options: Option 0: Do nothing new. SHA-1 is soft deprecated, but still a fully viable option in TLS 1.3 if nothing better is installed. Option 1: Explicitly state that TLS 1.3+ clients must not trust SHA-1 signatures (but may trust full certificates, namely roots). Option 2: Distrust (option 1) and also prohibit endpoints from sending chains that rely on SHA-1 signatures to their peers when negotiating TLS 1.3. (aka, don't upgrade to TLS 1.3 until you've upgraded your certificates; self-signed roots still exempt) No change is proposed with regard to dealing with SHA-1 under TLS 1.2 beyond the current state. TLS 1.3 already prohibits using SHA-1 in CertificateVerify. This discussion is only for TLS 1.3+ non-root certificates. The TLS 1.3 release is not yet near (assume we're talking about 2016, when others are phasing out SHA-1 more strictly as well). I am in favor of #2, as I don't think the risk of keeping it in the spec is worth continued support (SHA-1 is on its way out, and TLS 1.3 shouldn't perpetuate its use). Viktor Dukhovni is in favor of #1, and considers prohibiting servers from sending SHA-1 certs to be sufficiently out-of-scope and not worth the interop risk (opportunistic encryption and direct trust of certificates, of note). Two opinions does not a working group make, so more input is clearly needed to move forward in any way here. This is only a preliminary call for opinions, and certainly not a policy deciding vote. The new reason to consider this: https://sites.google.com/site/itstheshappening/ Current draft language: https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-60 Start of the parent thread: https://www.ietf.org/mail-archive/web/tls/current/msg17956.html Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote: > The observation is still valuable in the sense that prohibiting values > > 1.3 would reduce the likelihood of a false positive by some > miniscule amount. In other words, I agree with ekr here, though we > could cap the value to 1.3. > > Maybe we could just define two values: one for TLS 1.3 (and greater, > presumably) and one for TLS 1.2. I don't see any value in protecting > 1.1 or 1.0 from downgrade any more given relative prevalence of those > protocols and their age. Two values seems like a good compromise to me if one isn't considered sufficient. I don't particularly want them changing in the future so old (e.g. TLS 1.3, in a future with TLS 1.4+) implementations don't need to worry about seeing something new here and making a mistake. Checks would be for one of two 64-bit values, rather than 56-bit values with a byte with a possibly unknown value. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote: > On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett > wrote: > > > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote: > > > The observation is still valuable in the sense that prohibiting values > > > > 1.3 would reduce the likelihood of a false positive by some > > > miniscule amount. In other words, I agree with ekr here, though we > > > could cap the value to 1.3. > > > > > > Maybe we could just define two values: one for TLS 1.3 (and greater, > > > presumably) and one for TLS 1.2. I don't see any value in protecting > > > 1.1 or 1.0 from downgrade any more given relative prevalence of those > > > protocols and their age. > > > > Two values seems like a good compromise to me if one isn't considered > > sufficient. I don't particularly want them changing in the future so old > > (e.g. TLS 1.3, in a future with TLS 1.4+) implementations don't need to > > worry about seeing something new here and making a mistake. Checks would be > > for one of two 64-bit values, rather than 56-bit values with a byte with a > > possibly unknown value > > > My assumption here was that the client would do the following: > > 1. Look to see if the server negotiated its highest version. If so, then > all is good. > 2. If the server did not negotiate the highest version, then look for the > sentinel. > If it's set, you have a downgrade. > 3. (Optional) If you have a downgrade, parse the last byte to see the > server's actual version. > In any case, abort. > > What have I missed? A 64-bit sentinel can be trivially checked as a 64-bit uint. If we have an open-ended series, we could have implementations checking for a set of 64-bit integers rather than a 56-bit followed by another byte to be inspected. I'm being paranoid, yes, but it's simpler just to have a round number bits value or two and I don't think you get much by encoding further information. It also has a slightly better collision risk, though it's already down quite low. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR for anti-downgrade mechanism
On Saturday, October 17, 2015 05:53:57 pm Eric Rescorla wrote:
> On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett
> wrote:
> > A 64-bit sentinel can be trivially checked as a 64-bit uint.
>
> And a 56-bit value can be trivially checked by masking off the last byte.
> Or, memcmp().
My point is that one is more trivial and someone might check for 64 when they
shouldn't be. It's the same thought process that deals with bad user agent
sniffing; developers come up with algorithms that are ideal now, not
necessarily in the future.
It's not a world-ending complaint, but I do think it's simpler to just use a
uint64 or 2.
> > It also has a slightly better collision risk, though it's already down
> > quite low
>
>
> Given that the TCP checksum has a false negative rate far higher than
> 2^{-56} and
> any TCP errors cause TLS handshake failures, this doesn't seem like much of
> an argument.
I'll concede the collision risk argument on that point, then. As I said,
already smaller than it was in the first proposal.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Controlling use of SHA-1
I'm in favor of this change as well. It annoys Viktor, as it changes the fallback in a way that isn't ideal for some cases that trust the cert directly or with OE, but I think it's better than the alternative. Dave On Wednesday, October 21, 2015 03:17:44 pm Eric Rescorla wrote: > I think this is the right answer and parallels what we are doing with PSS. > > -Ekr > > > On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson > wrote: > > > The current draft permits the use of SHA-1 in the certificate chain, > > which gives SHA-1 a free pass indefinitely. Since we expressly forbid > > the use of SHA-1 for signing in TLS itself, we can just permit clients > > to include it in "signature_algorithms" and use that to determine > > whether SHA-1 is acceptable. > > > > That means that clients that want to disable SHA-1 (real soon now, we > > promise), can signal that preference cleanly. > > > > I've opened PR #317 for this, but the commit is probably more useful > > to review, since I built this on top of ekr's client authentication > > changes (to avoid messy rebases): > > > > > > https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Controlling use of SHA-1
On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote: > Whether SHA-1 in the chain is used to make trust decisions is only > known to the client, and the server MUST NOT preempt that by denying > the client access to whatever chain it has on hand. Can we please just fix this issue properly and add an "any(0xFF)" value to the enum so clients can explicitly tell the server that they're capable of trusting certs directly (or is doing OE) and the hash is potentially irrelevant? Note that the current proposed change does not break your use-case. Those clients can simply offer SHA-1 support indefinitely. Sure, they don't strictly support using SHA-1, but they support receiving certs using it, which is all the signal is really for. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension
Congrats on releasing an RFC that has day one 100% server support. :p Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Allow NamedGroups from the server?
On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/292 > > Presently, RFC 4492 only specifies the EC points it can support in > ServerHello, but does not let the server indicate which EC curves it > supports. Unless I'm missing something, this means that there's > no way for the server to indicate what groups it would support. > > That seems less than ideal. There seem like three options here: > > 1. Put it in CertificateRequest > 2. Send it in ServerHello > 3. Do nothing. I prefer #2. I don't think encryption is necessarily required for this, but EncryptedExtensions is fine too (Martin's 2b). I'm generally against putting it in CertificateRequest, as we're reusing an existing hello extension so keeping it in a hello message (or it's trailing encrypted field) seems best. (restricted to TLS 1.3+ clients, though) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Allow NamedGroups from the server?
On Thursday, October 22, 2015 09:29:22 am Eric Rescorla wrote: > From an implementation perspective, I wouldn't be surprised if client > implementations choked on the server sending this. [...] Hence my side-note that we should be explicit that it's for TLS 1.3+ (even if it's implicit elsewhere). On Thursday, October 22, 2015 01:36:18 pm Martin Rex wrote: > Andrei Popov wrote: > > Then my argument would be: why send extra bytes in each ServerHello > > when TLS client auth is not used most of the time? In this case, > > CertificateRequest seems to be a better place. > > I'm perfectly OK with the server _not_ sending/including a TLS extension > "Supported Elliptic Curves" in ServerHello if the server is not going > to request a client certificate. Yes, I would expect we want it in TLS 1.3+ ServerHello (or EncryptedExtensions) IFF the server is going to request a client cert. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Controlling use of SHA-1
On Thursday, October 22, 2015 02:18:30 pm Andrei Popov wrote: > What if we just made an explicit exception for root cert hash algorithms and > not constrained them by the client's alg list? +1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension
On Thursday, October 29, 2015 11:00:04 am Viktor Dukhovni wrote: > On Thu, Oct 29, 2015 at 03:07:58PM +0100, Hubert Kario wrote: > > On Wednesday 21 October 2015 20:17:31 Dave Garrett wrote: > > > Congrats on releasing an RFC that has day one 100% server support. :p > > > > oh, I'm sure there's at least one server out there that is intolerant to > > this one specific extension ]:-> > > When the extension was first enabled in OpenSSL 1.0.1g there were > (and perhaps some are still left unpatched) Cisco IronPort SMTP > servers that could not handle the extension. Now I'm just curious: How? Where they essentially just intolerant to _any_ new extension or one of a certain length? Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Just ditch compression
On Sunday, November 01, 2015 07:53:50 pm Russ Housley wrote: > I thought we already decided to remove compression from TLS 1.3. We did. See here: https://www.ietf.org/mail-archive/web/tls/current/msg17941.html On Thursday, October 08, 2015 10:10:51 pm Scott Arciszewski wrote: > Compression has no place in Transport Layer Security. [...] > Further bikeshedding is just embarrassing. The bikeshed was officially demolished. Compression will not be in TLS 1.3. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-1 patch updated with Russ' suggestion
On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote: > I'd like it to say: > > * The signature algorithms of self-signed certificates are > not subject to any constraints on either the supplicant or > the verifier. They are not required to match the supported > signature algorithms of the peer, are not required to avoid > deprecated algorithms, and their self-signatures SHOULD NOT > be checked. Why "SHOULD NOT be checked"? I don't think it needs to say anything about checking self-signatures here, one way or another. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-1 patch updated with Russ' suggestion
On Thursday, November 05, 2015 05:05:02 pm Viktor Dukhovni wrote: > On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote: > > > On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote: > > > I'd like it to say: > > > > > > * The signature algorithms of self-signed certificates are > > > not subject to any constraints on either the supplicant or > > > the verifier. They are not required to match the supported > > > signature algorithms of the peer, are not required to avoid > > > deprecated algorithms, and their self-signatures SHOULD NOT > > > be checked. > > > > Why "SHOULD NOT be checked"? I don't think it needs to say anything about > > checking self-signatures here, one way or another. > > The verifier always has a trusted out-of-band copy of each > trust-anchor. Checking the self-signature may needlessly run into > problems when its deprecated algorithm is no longer even implemented > in the crypto library. And yet the trust-anchor is still fine. Ideally, if the implementation is trusting certs as a whole, then it should be attempting to validate self-signatures upon addition to the trust store. If the cert received matches exactly, then it has been checked; redoing it isn't helpful. I note "attempt to validate" and agree that failing but still agreeing to trust the cert could be fine. Essentially, I'd rather it say something to the effect of: "Trusted self-signatures SHOULD be validated before adding to a trust store and SHOULD NOT be re-checked at runtime." But we're getting slightly out of scope here, which is why I'm thinking that elaborating on this topic exactly as suggested is not needed in the document. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data limit for GCM under a given key.
On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote: > Update: we discussed this extensively in Yokohama and based on Watson's > feedback and offline comments from David McGrew, the consensus was that we > needed to add some sort of rekeying mechanism to support long-lived flows. > Expect a PR on this next week. > > Note: We'll still need guidance to implementations on when to re-key, but > we don't expect to have a hard protocol limit. If re-keying is back up for discussion, let me restate my request for it to be routine, rather than only an niche-case feature. Any re-key schedule should be considered valid, but the spec should set a "SHOULD"-level requirement that the minimum be once every N hours or M terabytes, whichever comes first (where N & M are some bike-shedable numbers with some expectation of randomization in values for each period). Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data limit for GCM under a given key.
On Friday, November 06, 2015 10:54:02 pm Eric Rescorla wrote: > I don't believe time-based guidance is useful here, given that it's highly > situation specific rather than derived from reasoning about the properties > of the cipher. One reason to have a regular interval between rekeys is to ensure that it's a standard operation, rather than something implementations in many use-cases never see and possibly muck up when they eventually do. The time does not need to be short, though, and can vary by algorithm and implementation discretion. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#345: IANA Considerations
On Tuesday, November 17, 2015 02:14:00 pm Ilari Liusvaara wrote: > All current registered/proposed ciphersuites that work in TLS 1.3 are > *-GCM or *-POLY1305 ones (with DHE or ECDHE). DHE AES CCM is still in the list, even after the changes in the current proposal. ECDHE AES CCM is not as it's not standards track. There's an argument that it should be promoted alongside ECDHE AES GCM, however we're not really recommending CCM so that's probably not desired (and I don't know if it has had enough use to be considered recommended). There will likely also be AES OCB, at some point. On Tuesday, November 17, 2015 02:17:05 pm Viktor Dukhovni wrote: > I'm well aware of that, I'm just wondering whether the "Recommended" > column should cover recommendations for TLS 1.2 as well TLS 1.3? Yes. The following is in the backwards compatibility appendix in the current draft: "If an implementation negotiates use of TLS 1.2, then negotiation of cipher suites also supported by TLS 1.3 SHOULD be preferred, if available." At the end of the day, though, it's just a qualified "SHOULD". We're just talking recommendations. This isn't a diediedie RFC. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3
On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote: > I actually looked at the Editors's Copy. The description is a mess: It > seemingly first requires key_share extension, even for the first > ClientHello... Now, that extension can't be empty... And then proceeds > to say to omit it if client has no shares to send... Which looks like > it is mutually contradictionary. We went back and forth on whether to omit or require an empty extension. It looks like we have a mix of the two left in there that need fixing. (I think something got merged weird) Thanks for pointing this out. I think it might be easier if we just required the extension for all cases where (EC)DHE suites are offered, and have it empty to request a server choice, instead of an omitted extension. If I remember correctly, that's what I had originally. One way or another, it needs to be fixed to be consistent. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Replacing HelloRetryRequest in TLS 1.3?
HelloRetryRequest is annoying. Is there any way we can replace it with something? I know our options are limited, here. We can't mandate offers for everything, not just due to constrained environments, but also because post-quantum keys could get too big. The main thing that comes to mind would be to provide a way for a server to respond to a client with a ServerConfiguration, but not a hello, and put group support in there (maybe a whole supported_groups extension). Clients that don't provide the needed key would get a config and a fatal alert telling it that it needs to use a supported group from that config. The client could then retry as it does now or do 0-RTT with early data, which could cut an RTT out of the current flow. (This is similar to the QUIC way of doing things.) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
