Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
On 10/23/2017 12:39 PM, Ackermann, Michael wrote: 2. Modifying Server, application and logging infrastructure is a huge, expensive proposition, that executive management would not be receptive to at all. Not to mention the logistics to follow if they were. I'd just like to have everyone stop and focus on this, right here. This is the crux of everything. It takes effort and resources to upgrade your systems, and you don't want to do it. Tough; this is not the TLS WG's problem. The job here is to design the most secure protocol possible, and weakening things significantly to accommodate legacy methods is not a realistic option. Organizations will *always* have to expend effort and resources to upgrade to better systems. If that can be reduced without affecting security, great, but if not, then you're just going to have to accept it. People should not be here arguing against technical improvements; they should be with their managers explaining the simple reality of the situation. Yeah, I know it's hard to explain to executive management that they are not in control here, but they aren't. I count at least 400+ messages on this list on this one topic. The answer is still "no". You're not getting a cheap drop-in replacement for your existing insecure use of static RSA keys out of this WG. Fixing devil's advocate qualms like whether or not clients have to send an extension is not enough to get even a rough consensus. Nontrivial, but very much viable, effort and resources will be required to upgrade. https://en.wikipedia.org/wiki/Technical_debt Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Agreed; this conversation is not going to get anything to a real WG consensus without causing people to flee the WG. The hard sell just makes people more and more skeptical that this is really well intentioned. Please, let's just let this mess die. As Rich Salz has stated previously, we should just recommend those unwilling to change their ways immediately to stay on TLS 1.2 for a few years whilst they transition to something less horrible that can work with TLS 1.3. And, that less horrible thing need not suck up a billion more posts here. Dave On 10/20/2017 10:08 AM, Ted Lemon wrote: On Oct 20, 2017, at 9:54 AM, Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>> wrote: I can say for myself that there was a really strong hard sell on the notion of doing this in Prague. Not being sufficiently paranoid, my general sympathy for people facing hard problems led me to consider what they were proposing, but each time they came up with something, someone with more paranoia fu than I have pointed out a hole in it. During that period there were several periods when I was reluctantly willing to consider some less-bad version of draft-green. This is a long way from "want," and even a pretty long way from "support." My personal feeling having been peeled off the herd and hard-sold like this is that there is some really powerful motivated reasoning going on here, and that the working group should just stop entertaining this process. Weakening TLS is not the right way to approach the problem that has been described here. I hasten to add that I don't think the people doing the hard sell are bad people, or that they didn't have good reason for trying to do it. My point is simply that we've been collectively sucked close to a black hole here, and we need to take a step back from it. In the same sense that LEOs who want key escrow have good reason for wanting it and are not bad people for wanting it, so too with the people pushing this proposal. But like key escrow, this proposal is not beneficial for end-users or for security as a whole. In order for it to make sense to go forward with this proposal, two things would have to be true that I don't think are true. First, we would have to agree that user security is not a primary goal. And second, we would have to agree that overall network security is not a primary goal. Discussing the details of how much security we are willing to give up, what attack surfaces that we could remove we are willing to leave in, only makes sense if we are willing to drop those two primary goals. Watching this conversation has been a really good learning experience for me, so I don't regret it, but I think we should stop. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-green-tls-static-dh-in-tls13-01
This thread blew up rather quickly. Replying on a topic with quotes from various posts, below: On Saturday, July 08, 2017 05:09:12 am Stephen Farrell wrote: > On 08/07/17 03:06, Ackermann, Michael wrote: > > Converting all session traffic to clear text is not a viable > > alternative for ANY enterprises or industries that I am aware of. Could we please drop the plaintext straw man here? The alternative is building a system that doesn't rely on outdated methods, rather than shoe-horning them into TLS 1.3, not ditching encryption. > > In > > particular those in financial sectors. Security policies, legislation > > and in many cases just good practice would not allow for this. We are > > compelled by these factors to encrypt all data in motion. But we > > still need to manage our applications, networks, servers and clients. > > Hence the need to decrypt traffic as outlined in this draft. > > That assertion of necessity is blatantly false. > > It is entirely feasible to decrypt and re-encrypt in many > cases and for that to be efficient and to meet regulatory > needs. > > If some systems are so badly designed that doing that while > updating to tls1.3 is a showstopper then that's down to bad > design or other bad practices. Fixing those is the place to > spend effort instead of spending effort on breaking TLS. > > Other users of TLS ought not suffer on the basis of such > bad reasoning. +1 It is not the job of the TLS WG to make handling internal requirements of organizations easier with their existing systems in spite of the obvious risks that can be avoided. A drop-in replacement for a theoretically legitimate usecase is also a drop-in replacement for very much illegitimate usecases. Making this a standard is not the way to go here. An argument could be made for informational RFC status rather than standards track, but even then, it's dangerous. On Saturday, July 08, 2017 01:39:43 pm Watson Ladd wrote: > On Sat, Jul 8, 2017 at 10:17 AM, Stephen Farrell > wrote: > > Is it bad faith if the server is compelled to enable this > > wiretap interface? For a wiretapper this is a great scheme, > > as they only need to force it to be turned on and accept a > > tiny bit of data and then they can pick up those packets > > from anywhere without having to deal with problems at the > > web server end. So no need to even re-imburse the web server > > for the intercepted access anymore. > > The same applies to static RSA ciphersuites. I understand your desire > to move on with TLS 1.3, but we did burn what seemed to be a somewhat > important usecase to some people, and this draft demonstrates that TLS > 1.3 can be deployed in datacenters without hurting that usecase. As > much as I think enterprise networks are suffering from bad design > decisions that solve problems with boxes and not endpoint changes, > this is a problem people are claiming to face, and there are some > security implications. The organizations that took the easy way at the time now are being told to take a harder way that is more secure. (and are consistently posting to this list with amnesia, acting like we told them to use plaintext) They don't like that; we shouldn't care. We should consider standardizing better solutions for this problem, without regard to how much old systems will have to adapt their design. This has come up on this list MANY times, and each time the end result of discussion was to not revert security decisions made to improve TLS. Releasing a standards track (or even informational) RFC on how to do exactly that using all the old methods, with some tweaks, defeats the purpose of making those security decisions. I'm getting a bit of déjà vu from this thread, and think the same answer should come as from previous threads on the topic: no, please come up with something new. I don't see the proposed document being anywhere close to getting consensus for adoption by the TLS WG. For the stubborn, an (independent) informational RFC would get far less (but nontrivial) opposition. Dave PS Please avoid the "but they'll do whatever they want anyway" comebacks. If the response to not accommodating static keys anymore is to stay with TLS 1.2 forever, then at least they'll be open in their desire to avoid change at all costs. We should not treat this like a hostage scenario. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On Friday, July 07, 2017 03:02:43 am Matthew Green wrote: > https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 This document uses the terms: "Ephemeral (EC)DHE" & "Static (EC)DHE" The 'E' stands for ephemeral. Regardless of the technical, security, political, logistical, ethical, and whatever merits of this document, could you please make the terminology not hurt my brain? The former is the standard ATM machine silliness, and the later is contradictory and only vaguely viable by fiat of explicitly writing out the silliness: https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01#section-1.1 > This document introduces the term "static (elliptic curve) Diffie- > Hellman ephemeral", generally written as "static (EC)DHE", to refer > to long-lived finite field or elliptic curve Diffie-Hellman keys or > key pairs that will be used with the TLS 1.3 ephemeral ciphersuites > to negotiate traffic keys for multiple TLS sessions. > > For clarity, this document also introduces the term "ephemeral > (elliptic curve) Diffie-Hellman ephemeral", generally written as > "ephemeral (EC)DHE", to denote finite field or elliptic curve Diffie- > Hellman keys or key pairs that will be used with the TLS 1.3 > ephemeral ciphersuites to negotiate traffic keys for a single TLS > sessions. It should be simply: "Ephemeral (EC)DH" & "Static (EC)DH" Or just: "(EC)DHE" & "Static (EC)DH" (or even "(EC)DHS" if you want to use a similar scheme for both) My argument is that you've got to be able to come up with better terminology than "ephemeral (elliptic curve) Diffie-Hellman ephemeral". Using the same word twice in the same term with slightly different implications is... messy and confusing. Dave PS Response on the merits of the spec to follow in another post. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)
On Friday, July 07, 2017 11:14:10 am Salz, Rich wrote: > On Thursday, July 06, 2017 10:01:08 pm Dave Garrett wrote: > > Just as a clarification, all new RFCs should ideally meet all of the > > following > > criteria: > > * AEAD only > > * PFS only > > * TLS 1.2 and 1.3 support > > * no TLS 1.0 or 1.1 support (let alone SSL) > > * no use of broken hashes (MD5, SHA1, etc.) > > That's a good idea. > > Want to throw together a quick draft for curdle or AD-sponsored SAAG? I was just enumerating the points that seem to have a general consensus in this WG and come up each time a new doc is discussed. I was going for FAQ, not RFC. ;) That said, if we think there could be an actual benefit to formalizing this, probably with more detail (such as in Ilari's follow-up), that would be something I'd support. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Truncated HMAC: what to do with the MAC key?
On Saturday, July 08, 2017 12:38:18 am Peter Gutmann wrote: > Andreas Walz writes: > >different TLS implementations do not seem to agree on how to implement > >truncated HMAC > > It also says something about the status of this capability if three of the > four known implementations can't interoperate. If it's taken fourteen years > (RFC 3546 was 2003) for someone to notice that the implementations don't > work/interoperate then maybe the capability should be marked as deprecated or > obsolete or unused or something. In progress; the Truncated HMAC TLS extension is prohibited in implementations that support TLS 1.3+ as of the current draft. https://tools.ietf.org/html/draft-ietf-tls-tls13-21#page-127 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)
On Tuesday, July 04, 2017 07:21:44 am Ilari Liusvaara wrote: > However, this requires > TLS 1.2 or newer, but that should not be a problem. > > - The proposed ciphersuites are really bad. Just as a clarification, all new RFCs should ideally meet all of the following criteria: * AEAD only * PFS only * TLS 1.2 and 1.3 support * no TLS 1.0 or 1.1 support (let alone SSL) * no use of broken hashes (MD5, SHA1, etc.) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Closing on 0-RTT
On Sunday, June 11, 2017 11:18:03 am Eric Rescorla wrote: > Here's what I propose to do: [...] > - Mandate (SHOULD-level) that servers do some sort of bounded > (at-most-N times) anti-replay mechanism and emphasize that > implementations that forbid replays entirely (only allowing > retransmission) are superior. [...] > Here's what I do not intend to do. [...] > - Mandate (MUST-level) any anti-replay mechanism. I do not believe > there is any WG consensus for this. Whilst bounded replay protection isn't ideal, I wasn't aware of it being opposed to the point where we couldn't make it the bare minimum. There really needs to be some floor to the mess here. If I've followed all of the discussion accurately, there may be a rough consensus that mandating with a MUST-level _some_ kind of anti-replay mechanism which MAY be implemented at the application layer as appropriate. (with a SHOULD-level requirement that it be done in the TLS implementation; MUST-level if we can actually agree to mandate bounded as a minimum, with better handling at the application level) In other words, either the TLS implementation MUST have replay protection or the application protocol profile MUST have its own replay protection (instead, or preferably in addition to a bare minimum). Replay protection would be required by TLS, but could be delegated to the application; people that want to do really unsafe stuff can define its replay handling mechanics there. This (heavily qualified) set of requirements would define TLS to be safe, so long as people stay within the known bounds laid out by the spec and profile(s) (with the potential for dubious profiles hand waved away...). Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] adopted: draft-ghedini-tls-certificate-compression
On Wednesday, June 07, 2017 07:03:55 am Piotr Sikora wrote: > > Additionally, there's one bit of the spec which I question the need for: > > zlib support. Unless someone can show a legitimate case where zlib will > > consistently and notably outperform brotli, I don't see the point in > > defining it as an option. This is a bran new extension; we don't need > > backwards compatibility here. There's been a general consensus in this WG > > to avoid algorithm agility unless there's a real reason for it, so I > > propose we ditch zlib support and make brotli the default and only > > specified at the start (promoting it to id 0). Should some problem arise in > > the future where we actually need to use a decades old compression > > algorithm, it can be added later. Furthermore, we should probably define a > > pre-defined dictionary for brotli to use here which is based on common > > strings in certificates, rather than its default one for the general web > > (if such a thing is practical to do here). This could boost efficiency here > > and make it even more worth preferring (also likely reducing t he size of said dictionary, as the default one is 120kB). > > To play devil's advocate, why do suggest we ditch zlib and not Brotli? > > I just did an experiment using certificate chains for facebook.com > (ECDSA) and google.com (RSA). > [...snip...] > > As you can see, at level 1, Brotli is easily outperformed by gzip with > and without dictionary, at level 6, both are basically the same, and > at level 9/Z, Brotli wins by a small margin in terms of file size. > > However, you need to keep in mind that Brotli has significantly higher > cost of compression, both in terms of CPU and memory allocations > (>40MB at higher levels), which might be unacceptable in some > environments. > > Don't get me wrong, I'm a big fan of Brotli, but unless we want to > squeeze every single byte out of the compression and/or use > pre-compressed certificates, then maybe Brotli isn't the best and only > choice here? This is a convincing argument to me. Thanks for the data. Given this information, I agree that supporting both algorithms can be helpful here, depending on server hardware constraints. I'm still curious to know if we can potentially create a lightweight cert-specific dictionary here that can boost things a bit. Or, is the QUIC one largely based on certs too? As to your devil's advocate suggestion: ... yeah, if Brotli doesn't give us any useful gains here over zlib, even with a new dict, I'd be ok with not specifying it for use. Your test does show it getting a small win at max compression, so that may not be the case. After fiddling with defining a new dict, test data against a larger set of certs could be useful. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] adopted: draft-ghedini-tls-certificate-compression
On Wednesday, June 07, 2017 01:38:59 am Raja ashok wrote: > So I suggest we should consider compression on client certificate message > also. +1 Additionally, there's one bit of the spec which I question the need for: zlib support. Unless someone can show a legitimate case where zlib will consistently and notably outperform brotli, I don't see the point in defining it as an option. This is a bran new extension; we don't need backwards compatibility here. There's been a general consensus in this WG to avoid algorithm agility unless there's a real reason for it, so I propose we ditch zlib support and make brotli the default and only specified at the start (promoting it to id 0). Should some problem arise in the future where we actually need to use a decades old compression algorithm, it can be added later. Furthermore, we should probably define a pre-defined dictionary for brotli to use here which is based on common strings in certificates, rather than its default one for the general web (if such a thing is practical to do here). This could boost efficiency here and make it even more worth preferring (also likely reducing the s ize of said dictionary, as the default one is 120kB). Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI
Correct; certs are never in the clear. There is no scenario where anything will be unencrypted after the hellos in TLS 1.3+. If you're doing anything with an old system that relies on this, the general advice is to upgrade your old system to not do that anymore. If you're logging traffic from some server(s), log the traffic on those server(s) instead of MitMing. See old threads for more detail. Dave On Tuesday, June 06, 2017 08:36:38 pm Toerless Eckert wrote: > So no options in TLS 1.3 that make it possible to see the server cert in the > clear ? > > On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote: > > On 06/02/2017 08:28 AM, Toerless Eckert wrote: > > > Another candidate use case coming to mind eg: auditing tht is required in > > > many eg: financial > > > environments. In the past i have seen even the requirement for the whole > > > data streams to be unencrypted > > > for auditing. Maybe that market segment would also be able to get more > > > privacy but maintain a > > > relevant level of auditing if the auditing relevant class of information > > > was visible via > > > the cert. > > > > That use case has been extensively discussed (look for the thread > > "Industry Concerns about TLS 1.3", also a fair bit of hallway > > discussions), and was not seen to provide a compelling argument for any > > change in TLS 1.3. There are purely server-side options that should be > > able to provide the necessary functionality (crypto details omitted for > > now). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Security review of TLS1.3 0-RTT
On Tuesday, May 30, 2017 05:38:02 pm Victor Vasiliev wrote: > TLS isn’t a magical “transport security solution”, it provides a very specific > set of explicit security guarantees to the applications that use it. It can > be > used as a building block for the secure systems, but at the end of the day, > the > security of a system hinges on the designers’ understanding of the security > contracts provided by individual components. > > TLS 1.3 as-is does not remove any of the replay protection guarantees provided > by TLS 1.2. However, if the user chooses to waive said protection in order to > do 0-RTT, they can do that with an API explicitly designed for that purpose. +1; In fact, I'd suggest sticking this almost as-is into the spec somewhere. > C. “Nebulous” replay bound. 0-RTT data can be replayed, but only for some > finitely bounded number of times. I initially wanted to call this “weak > replay protection”, but that felt too generous. > > Normally I would dismiss this as a useful security property due to its > inherent > vagueness, for the same reasons that “your server is too far away for > nanosecond-level timing attacks on Intel CPUs” is a property that no serious > cryptographer would admit in a research paper. However, you’ve pointed out > some > interesting side channel leaks, which exist even without 0-RTT, but can be > amplified by replaying 0-RTT queries. C, like B, mitigates this, so this is a > meaningful property to provide. > > Let’s talk about what mechanisms are and are not viable for the nebulous > bound promise. There is one relatively straightforward mechanism for limiting 3rd party replay: A 3rd party replaying 0-RTT PSK will fail to successfully complete the handshake (after 1-RTT), as it would generally have the identity/ticket but not the key behind it (e.g. resumption_master_secret). The 0-RTT data will have already been processed, however a server detecting any PSK failure could then flag the offending ticket/IP and reject all future 0-RTT attempts for some time period (e.g. ticket lifetime). This would limit replays to one per server, or less if this banned 0-RTT state is shared across servers. The notable problem with this mechanism is that a 0-RTT DDoS, could easily balloon the state size rather significantly, if not careful. Servers would have to be fine with budgeting resources for a nontrivial state in the event of attack, even if they don't need it during normal operation, but that could at least be doable. A replay from the 1st party that is expected to have the correct key/secret or from a 3rd party that has stolen it would not be mitigated by this system, but that's much harder for an attacker to attempt, at least. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13)
On Monday, May 22, 2017 08:29:13 pm Viktor Dukhovni wrote: > Setting a collision-resistance floor rather than naming some list > of algorithms makes more sense to me, but if the WG really feels > that naming some "verbotten" algorithms is better, so be it. My preference would be to do both. Call out the ones we have codepoints for by name (MD5/SHA1/SHA224), then have a general collision-resistance floor value for everything else. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Better weak hash language (was Re: AD Review of draft-ietf-tls-tls13)
On Monday, May 22, 2017 05:31:55 pm Viktor Dukhovni wrote: > So if putting the consensus to ban MD5/SHA-1 in its *proper context* > is consistent with the WG consensus, let's do that. Yes, please. Citing discussion elsewhere in this thread (that probably should've all been forked off with a different subject long before now...): On Monday, May 22, 2017 05:00:20 pm Nico Williams wrote: > On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote: > > On Tue, May 23, 2017 at 5:43 AM, Nico Williams > > wrote: > > > Proposal: > > > > > >Clients SHOULD/MUST NOT accept server certificates, or certificate > > >validation paths, where the server certificate or intermediate > > >certificates (but not trust anchors) are signed with "weak" signature > > >algorithms, unless the client is not expecting TLS to strongly > > >authenticate the server (e.g., for opportunistic use) or where the > > >client has previously learned and cached the server's certificate. > > > > I don't think "strongly authenticate" is useful here. I think the > > requirement is that the RP must not accept these algorithms in any > > context which would require validating signatures made using them. > > Well, I want it to be crystal clear that the "not MD5 and such" > requirement need not apply to opportunistic TLS usage. If you don't > like my text, maybe you can propose your own. My issue with this area is that we've got this fairly weird two tiered problem where we're still pretending SHA-1 is vaguely acceptable in some scenarios where certificates are being validated, and thus we need two sets of language: one for weak hash MUST NOTs and another for weak hash SHOULD NOT. The current text was written before SHA-1 was broken back in February, so, while the topic of changing language we had consensus on is up, I'd really like to make SHA-1 completely banned for standard certificate authenticated TLS 1.3+ connections alongside MD5. To do this in a non-messy way, we'd have to delete the SHA-1 special-casing and state that TLS 1.3+ implementations can only use deprecated hashes (MD5/SHA1/SHA224/etc) if explicitly doing opportunistic encryption or some scenario where trust can be established without validating them. Again, the trust anchor gets an exception here due to it being trusted directly without need for validation, and they can get away with just a "NOT RECOMMENDED". If we can agree to this, then the resulting text will end up being far less problematic. If we can't get a consensus for this, I seriously propose citing RFC 6919 s3. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] AD Review of draft-ietf-tls-tls13
On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote: > Which brings us to some more undesirable layer violation in the current > draft. The language in question is appropriate for updates to RFC5280, > but does not belong in TLS. The problems in question are largely > already addressed elsewhere (as CAs no longer issue MD5, SHA1, ... > certificates, browsers no longer support them, ...) and continue to > be further remediated in the appropriate standards and products. > > Therefore delete: > >Section 4.2.3 (Legacy algorithms paragraph final sentence): > > ... TLS 1.3 servers > MUST NOT offer a SHA-1 signed certificate unless no valid > certificate chain can be produced without it (see > Section 4.4.2.2). > >Section 4.4.2.2: > >... This fallback chain MAY use the deprecated SHA-1 hash >algorithm only if the "signature_algorithms" extension provided by >the client permits it. If the client cannot construct an acceptable >chain using the provided certificates and decides to abort the >handshake, then it MUST abort the handshake with an >"unsupported_certificate" alert. > >Section 4.4.2.4: > >Any endpoint receiving any certificate signed using any signature >algorithm using an MD5 hash MUST abort the handshake with a >"bad_certificate" alert. SHA-1 is deprecated and it is RECOMMENDED >that any endpoint receiving any certificate signed using any >signature algorithm using a SHA-1 hash abort the handshake with a >"bad_certificate" alert. All endpoints are RECOMMENDED to transition >to SHA-256 or better as soon as possible to maintain interoperability >with implementations currently in the process of phasing out SHA-1 >support. No. I strongly oppose stripping all off this out. > I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES, > MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1 > or even MD5. They're not listed as possible field values anywhere directly in the TLS spec. If someone wants to add a line to one of the "MUST NOT" lists somewhere for all hashes weaker than SHA-1, that sounds fine to me. > Opportunistic unauthenticated TLS ignores the peer certificate and should > not have to fall back to cleartext just because some certificate in the > chain is not sufficiently sexy. There are other legitimate use cases where > the restrictions above are inappropriate. Opportunistic unauthenticated TLS isn't the protocol we're defining here. If your goal isn't authentication, then by all means violate the requirements laid out for authentication. I have no problem making that explicit, if desired, however this is not the primary desired operating mode of TLS. > The reason I am pointing this out is that I just had to waste a bunch of > time convincing the rest of the OpenSSL team to ignore the draft language > in question, and just stick with whatever "security level" (floor on > algorithm strength) the application or default settings requested. This > already excludes MD5 by default, and we'll likely adjust the collision > resistance rating of SHA-1 from 2^80 to its reported ~2^64 strength (from > the recent Google collision announcement), after which SHA-1 will also > be excluded at security level 1. This will be done in the X.509 ala PKIX > code and not the TLS code, and applications that ignore the chain or do > DANE-EE(3), ... will not be affected. > > I propose that the current draft language is just a landmine for TLS > implementations, that addresses a non-problem (or more precisely a > problem that is more properly and well addressed elsewhere). TLS is already a minefield of problems. Enumerating many of them explicitly is a step forward to avoiding them more easily in the future. In a complex system, just fixing something in one place is not enough. If we list it as a possible option in the spec, we should be _very_ clear when it is crap. I'm aware that this is unavoidably messy. Viktor, your input has greatly helped improve the language here to accommodate varying use-cases, and I would personally prefer we work together to make the mess correct, rather than give up and delete the relevant text. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-04.txt
On Friday, May 19, 2017 04:18:03 pm Daniel Migault wrote: > 1) The current document mentions I-D.ietf-tls-rfc4492bis and > I-D.ietf-tls-tls13 as normative. We can wait for these documents to become > RFCs, but we can also dowref them to informational reference if we want to > move that document forward. I will leave the AD to decide, and changes if > needed can be done by the RFC -editor Listing TLS 1.3 as normative when it explicitly doesn't affect/support it is weird. I don't see the need for this to not be an informational reference. 4492bis lists TLS 1.3 as informative as well, yet is more relevant to it. I think just downgrading the reference is fine. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03
On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote: > In section 4, "these cipher suites MUST NOT be negotiated in TLS > versions prior to 1.2" should probably clarify that "these" cipher > suites are the new ones specified by this document. Probably should be: "the cipher suites defined in this document MUST NOT be negotiated for any version of TLS other than 1.2." The sentence mentioning TLS 1.3+ could be moved up to right after and just say: "TLS version 1.3 and later negotiate these features in a different manner." Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] AD Review of draft-ietf-tls-tls13
On Tuesday, May 16, 2017 12:37:42 pm Viktor Dukhovni wrote: >* RFC7250 raw public keys Just as a footnote to anyone reading this discussion that may not know: The current version of the TLS 1.3 spec explicitly recommends RFC7250 raw public keys as a viable option and provides the needed information on how to handle this in TLS 1.3. Anonymous cipher suite support has been dropped from TLS 1.3, and trust on first use raw public keys are the first of the two recommended alternatives. >* TOFU public key pinning Trust on first use public keys in unvalidated certificate chains is the second recommended alternative. https://tlswg.github.io/tls13-spec/#unauthenticated-operation https://tools.ietf.org/html/draft-ietf-tls-tls13-20#appendix-C.6 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)
On Tuesday, May 16, 2017 07:35:16 am Hubert Kario wrote: > On Monday, 15 May 2017 22:10:00 CEST Dave Garrett wrote: > > On Monday, May 15, 2017 07:56:44 am Hubert Kario wrote: > > > I respectfully disagree. That system requires tight coupling between the > > > TLS implementation and DNS. This is not something that facilitates TLS > > > deployment. We want more TLS/HTTPS deployment, not less. > > > > I completely understand why you'd disagree on these grounds. My argument is > > that whilst this does require a significant amount of coordination, it's a > > more productive route than just focusing on SNI encryption, which still has > > its own share of problems. (hence us not agreeing on a way to do it yet) > > Is there anything else sensitive in the Client Hello? Yes. (lower priority info, but nonzero) I'm of the philosophy that implementations should be open to arbitrary audit, but their messages should not give any info away that it doesn't have to. Frankly, figuring out how it can be misused is secondary; I assume it can. A hypothetical scenario: Lets say I've got a client using a device, and moving between multiple networks (e.g. joins various WiFi over time). Lets say the attacker is passive and cannot reliably know what the IP of our client is at all times. The user will most likely consistently use the same client software. Various different implementations will make various different choices with the many switches and options in TLS; fingerprinting implementations based on their ClientHellos is not that hard. If the user has changed anything from default that affects TLS via hellos, fingerprinting becomes much easier. This means that an attacker can one, guess what software the target user is using and make it easier to attack (and possibly decide to use active attacks at some point), and two, attempt to track a user with a changing IP across connections. Lets say our user goes through various WiFi networks and our attacker can listen in on all of them (not necessarily a tall ask), or we only care about a specific (set of) server(s) and can listen to their traffic. If the attacker can link the user to one IP, and see its ClientHello, then it can guess a window where the client switches from one IP to another, look for ClientHellos, and then narrow down the possibilities of who the target is in that list based on the prior fingerprint. If unique enough, or combined with other information to narrow it down further, the client can be identified across networks. There's of course other reasons clients can switch between IPs; Tor users can come out of different exit nodes over time. The point here is that not being able to fingerprint the ClientHello would make it much harder to track targets across IP changes. Additionally, whether or not a client is resuming a session is revealed in the ClientHello. This information can also be used to identify clients, and is itself potentially private information that the user may not wish to be disclosed. I'm sure we could come up with some other bits of information that get leaked that could be used in some creative way in the future. I also assume that some implementation will at some point put something incredibly stupid in its ClientHello that needs extra protection. I'd prefer we just attempt to always encrypt it all and call it a day. ;) > Either way, to properly > encrypt SNI with forward secrecy requires the same system that would be > necessary to encrypt the whole Client Hello. I get the impression that some people consider "proper" encryption of SNI to be something less important than getting it encrypted in any way. (e.g. a trial hashing idea was brought up) I'm not opposed to attempting to get a minimum viable SNI encryption scheme out there, but I think those efforts are better aimed higher. (and doing just SNI makes us less likely to consider full hello encryption in the future) > > The most practical short-term route would likely be to continue to hold our > > noses and expect cleartext SNI, but maybe provide a very simple way for > > servers to put a flag in a DNS record to opt-out entirely when they can do > > without. > > The point of encrypting SNI is so that you can hide a website on a shared > hosting host. If you have just one website on a host, there's nothing to > hide... Opting out by servers also makes the interesting targets more visible > (see also: email encryption). Point taken, but you can change your IP more often than your domain. Not using SNI at least increases the amount of effort required to figure out the destination. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)
On Monday, May 15, 2017 07:56:44 am Hubert Kario wrote: > On Saturday, 13 May 2017 07:21:06 CEST Dave Garrett wrote: > > On Friday, May 12, 2017 11:17:45 pm Christian Huitema wrote: > > > The "server DH Key" poses a significant forward secrecy issue. Suppose > > > that the key is compromised. Now the secret police can find out what > > > nasty sites was accessed by whom. That can be plus plus not good for > > > said dissidents. > > > > *This is the current situation.* "If the fix is broken, then it won't be > > fixed anymore" is not really that compelling of an argument, by itself. > > > > Of course the host DH key has an FS risk; it'd need to have a limited > > validity time and be rotated regularly. (probably weekly) > > you then need mechanism to indicate which DNS key share client is using or > all > the connections would start failing on key rollover. And have to deal with > all > the "fun" stuff related to key rollovers. It's possible to conceive of a way to do this with minimal trial decryption, or instead, we could just rotate the port with the key. (confusing firewalls is of course a problem, but that's something that could be dealt with) > > The private key > > would need to be protected and managed by the host (not the virtual > > servers) > > yes, the key MUST be assigned to a specific IP, not virtual host > > > > EKR did propose a TLS in TLS tunnel back in December 2015: > > > https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90Ftw. > > > It would effectively encrypt the "inner" Client Hello. > > > > Same basic concept, different implementation. TLS tunneling would provide > > some backwards compatibility; ClientHellos would still look like > > ClientHellos. I was just suggesting the simple generic route of encrypting > > everything in a non-backwards-compatible way (sent to a specified port that > > is set up to only handle that and reject everything else). I'd rather let > > stupid/incompatible stuff just break if we're designing a new opt-in > > system. > > > > The argument I'm making here isn't about implementation; it's about what to > > think about implementing to deal with the issues here. > > I respectfully disagree. That system requires tight coupling between the TLS > implementation and DNS. This is not something that facilitates TLS > deployment. > We want more TLS/HTTPS deployment, not less. I completely understand why you'd disagree on these grounds. My argument is that whilst this does require a significant amount of coordination, it's a more productive route than just focusing on SNI encryption, which still has its own share of problems. (hence us not agreeing on a way to do it yet) The most practical short-term route would likely be to continue to hold our noses and expect cleartext SNI, but maybe provide a very simple way for servers to put a flag in a DNS record to opt-out entirely when they can do without. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted hellos (was Re: "Encrypted" SNI)
On Friday, May 12, 2017 11:17:45 pm Christian Huitema wrote: > The "server DH Key" poses a significant forward secrecy issue. Suppose > that the key is compromised. Now the secret police can find out what > nasty sites was accessed by whom. That can be plus plus not good for > said dissidents. *This is the current situation.* "If the fix is broken, then it won't be fixed anymore" is not really that compelling of an argument, by itself. Of course the host DH key has an FS risk; it'd need to have a limited validity time and be rotated regularly. (probably weekly) The private key would need to be protected and managed by the host (not the virtual servers), and the public key would need to be given to the virtual servers to be listed in DNS for their domains. An attacker that can get that private key can revert the security to the current status quo, but the handshake would still set up an ephemeral DH key for FS of everything after the hellos (as is the current case, with the well known caveats with 0RTT data). An attacker that can reliably exfiltrate or completely control that key/host will almost certainly be able to surviel which virtual hosts are connected to no matter what we do. (or more precisely, I think that any gains you can make there are likely to be a lost cause) The only simple solution virtual servers have there is to not use a host you can't actually trust. Of course, if everyone just switched to IPv6, everyone can get their own unique IP, the offending virtual server nonsense becomes obsolete, and servers could opt-out of SNI entirely (e.g. via a flag in DNS). (yeah, those IPs are of course trackable, though more easily rotatable, but you're not going to get a perfect solution here without something like Tor) > EKR did propose a TLS in TLS tunnel back in December 2015: > https://mailarchive.ietf.org/arch/msg/tls/tXvdcqnogZgqmdfCugrV8M90Ftw. > It would effectively encrypt the "inner" Client Hello. Same basic concept, different implementation. TLS tunneling would provide some backwards compatibility; ClientHellos would still look like ClientHellos. I was just suggesting the simple generic route of encrypting everything in a non-backwards-compatible way (sent to a specified port that is set up to only handle that and reject everything else). I'd rather let stupid/incompatible stuff just break if we're designing a new opt-in system. The argument I'm making here isn't about implementation; it's about what to think about implementing to deal with the issues here. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Encrypted hellos (was Re: "Encrypted" SNI)
On Wednesday, May 10, 2017 03:28:48 pm Ilari Liusvaara wrote: > On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote: > > Yes, encrypted SNI was discussed and ultimately rejected. > > > > But do we really have to send the literal value? Don't we need to just make > > sure that the client and server agree on the host that the client wants to > > connect? > > > > Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending > > the salt and the resulting hash, making the server calculate the same hash > > with each of the virtual host names it supports and comparing with the > > client > > provided value? > > What makes encrypting SNI nasty is replay attacks. > > There also was proposal for putting SNI mapping into DNS (which limits the > leakage if DNS lookups are private). However, I came up with a way to use > that to attack HTTPS (the usual "default vhost" attacks). On Wednesday, May 10, 2017 04:24:05 pm Daniel Kahn Gillmor wrote: > On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote: > > It certainly was. But then the clear text SNI is a gaping privacy hole > > in TLS, the kind of issue that should keep us awake at night until it is > > resolved. We need to make sure that we make progress, rather than rehash > > the old arguments. Maybe we should invest some time and document the > > various proposals in a draft. I am willing to work on that. Any other > > volunteers? > > I agree with Christian's assessment of the problem, and i'd be > interested in collaborating on such a draft. > > The DNS folks are making strides to protect name information (the other > main place where this kind of data is leaking). TLS needs to keep up. Encrypted SNI has been talked to death, and coming up with new schemes that warrant air quotes in the subject around "encrypted" feels like a waste of time. Wouldn't it be better to just focus on finishing the encrypt-all-the-things approach and plan out a way to distribute a host DH key (+ a few params, e.g. port(s)+protocol(s) to use with encrypted hellos) via DNS to encrypt everything straight from the ClientHello? Stick a supported_groups in there as well and we can make HRR unneeded while we're at it. This would also protect against 3rd parties attempting to fingerprint clients via ClientHello parameters. (probably a few other things that could be listed that could be helped, too) Simply put, some of us were convinced a while ago that encrypted SNI isn't nearly as useful as it first seems, however fully encrypted hellos address that problem and more. I think it'd be better to work towards a more complete solution here than just worrying about SNI. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Issue #964: Shortened HKDF labels
On Monday, April 24, 2017 07:21:13 pm Eric Rescorla wrote: > Hence, the following proposal for the complete label, where the longest > string is 18 bytes. > > 16 tls13 ext binder# was external psk binder key > 16 tls13 res binder# was resumption psk binder key > 17 tls13 c e traffic# was client early traffic secret > 18 tls13 e exp master# was early exporter master secret > 18 tls13 c hs traffic# was client handshake traffic secret > 18 tls13 s hs traffic# was server handshake traffic secret > 18 tls13 c ap traffic# was client application traffic secret > 18 tls13 s ap traffic# was server application traffic secret > 16 tls13 exp master# was exporter master secret > 16 tls13 res master# was resumption master secret > 9 tls13 key# was key > 8 tls13 iv# was iv > 14 tls13 finished# was finished > 17 tls13 traffic upd# was application traffic secret > 14 tls13 exporter# was exporter > 13 tls13 derived# was derived > > Further bikeshedding? I think "tls13 c e traffic" is the only one that could be tweaked to be a little more obvious. Abbreviating "early data" as "ed", instead of just "early" as "e", would still fit and follow the same pattern as the other traffic labels. Other than that, this sounds fine. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Issue #964: Shortened HKDF labels
On Monday, April 24, 2017 12:39:32 pm Eric Rescorla wrote: > 9 bytes seems a bit cramped. What I suggest here is that we remove the "TLS > 1.3, ", as it was just there by analogy to the handshake context and then > we are back to having 18 bytes. > > If people feel like we should have some "TLS" prefix, I think "TLS " would > be enough, giving us 1 bytes. (assuming you mean 14 bytes here) If I remember correctly, in some discussion quite a while back, we decided we wanted to bake the version number into the labels. This could be done more compactly by adding a ProtocolVersion value (2 bytes) to the HkdfLabel struct. "TLS" could be stuck in there as a static 3 byte opaque string, with no length or space. (yeah, the combined plaintext will go "TLSclient hs traffic", but nobody needs to care) Also, why is HkdfLabel.length 16 bits instead of 8? Is there any conceivable scenario where we'd need to HKDF-Expand to more than 256 bytes, in our uses here? Unless I'm missing something, our values for this field range from 12-32 normally (or up to 64 with 512 bit). Ditching the extra byte here would salvage another byte for labels. (just an aside: HkdfLabel.length would be a lot more clear as to its meaning if it were named HkdfLabel.output_length, instead; too many length values here) With ProtocolVersion + "TLS" + dropped length byte, that results in a label space of 14 bytes, whilst still keeping the version number baked into the label directly. An extra couple of bytes could even be salvaged out of the HkdfLabel struct by ditching the lengths of the 'label' and 'hash_value' fields, though going this far may be overkill. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-tls13-19
On Tuesday, March 28, 2017 02:23:33 am Kaduk, Ben wrote: > Should Alert.level be Alert.legacy_level? Yep. Trivial to fix, so quick PR filed for it. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls13-19 section 1.2 cleanup
On Tuesday, March 28, 2017 11:31:56 am Short, Todd wrote: > I didn’t bring this up in the meeting this morning, but I’d like to see > section 1.2 “Major Differences from TLS 1.2” cleaned up. We don’t need to > list the changes at each draft. Instead, only the major difference from RFC > 5246, et al., should be included. It’s difficult to wade through this section > as written. > > I refer to RFC5246, section 1.2 as an appropriate (and useful) example. Yeah, this has come up a few times, also in another post here very recently. It's always been on a vague todo list to fixup. I've filed an issue just for this so we have it actually tracked. https://github.com/tlswg/tls13-spec/issues/923 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 4.1.2 Client Hello ammendment
On Tuesday, March 28, 2017 01:37:29 pm Mark Dunn wrote: > should the text that reads > ClientHellos will contain at least two extensions, > “supported_versions” and either “key_share” or “pre_shared_key”. > be changed to > ClientHellos will always contain extensions. > > Both "key_share" and "pre_shared_key" require other extensions, so "at > least two extensions" is incorrect. Um, that's still "at least two". ;) Taking a look at that section, there's a better line stating this just below in another paragraph on the same topic. I've posted a quick PR to rewrite this slightly to clean this up a bit. https://github.com/tlswg/tls13-spec/pull/922 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-tls13-19
Yes, a proper "differences from TLS 1.2" section needs to be written to replace the draft changelog. Dave On Tuesday, March 14, 2017 05:31:18 am Yoav Nir wrote: > Hi. > > I will give the entire document a more thorough read, but I wanted to comment > on section 1.2 earlier. Its title is “Major differences from TLS 1.2”, but > the content is a change-log. The kind of change-log that usually gets deleted > by the RFC editor. > > I hope we don’t plan to publish with sentences like “Allow cookies to be > longer”. OTOH I think it will be useful to have an actual “major differences > from TLS 1.2” section, but AFAICT it’s not yet written. > > Yoav > > > On 13 Mar 2017, at 19:30, Sean Turner wrote: > > > > This is a working group last call announcement for draft-ietf-tls-tls13-19, > > to run through March 27. Please send your reviews to the list as soon as > > possible so we can prepare for any discussion of open issues at IETF 98 in > > Chicago. > > > > Thanks, > > J&S > > ___ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Draft: Using DNS to set the SNI explicitly
On Friday, March 10, 2017 10:29:30 am Viktor Dukhovni wrote: > Instead of looking for a kludgey replacement SNI in DNS (that won't get > deployed, > and provides rather weak obfuscation) it seems more sensible to publish keys > in > DNS that make it possible to encrypt the entire client HELLO, SNI and all. +1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Comments to draft tls13-18
On Thursday, December 15, 2016 08:32:32 am Guballa Jens (ETAS-PSC/ECS) wrote: > - Page 108 (appendix C.4): "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." > TLS cipher suites for TLS1.3 and TLS1.2 are disjunctive, in my > understanding. Therefore I think this sentence does not make any sense. > Unfortunately the semantic of "cipher suite" has been changed from TLS1.2 > to TLS1.3, thus there are different definitions of this term for both TLS > versions. I've already updated this sentence for draft 19. https://tlswg.github.io/tls13-spec/#backwards-compatibility-security-restrictions Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
(replies to a bunch of ideas in this thread) As the person who lit the match under this latest bikeshed debate, personally, I don't see a strong consensus building here. Leaving the bikeshed unpainted seems like the option we're headed for, at this rate. I'm fine with TLS 1.3 if that's the result here. That said, I think I've been somewhat swayed to the TLS 4 camp with the "fourth version of TLS" message. It makes a kind of messy sense that's kind of fitting for TLS. I'm no longer against it. I've also suggested highlighting the year in the past, but only in the context of the title and messaging, not actually replacing the version number itself. I'd be ok with TLS 1.3-2017 (or something), not doing a find/replace of 1.3 and changing it to 2017, wholesale. That just feels even more confusing. Lastly, I am vehemently against the suggestion of ditching the TLS name in favor of SSL again, as was also brought up in this thread. SSL is dead and insecure, and that message needs to stay. We need to get people to stop conflating the two and making this worse, not accepting it. Dave On Sunday, November 20, 2016 08:16:07 pm Eric Rescorla wrote: > I mildly prefer TLS 1.3 to TLS 2 and TLS 4 (If we're going to rev the major > version number we should abandon the minor one). > TLS 2017 strikes me as quite bad; we're certainly not planning to do a TLS > 2018. I am strongly opposed to TLS 2017. > > -Ekr > > > On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner wrote: > > > At IETF 97, the chairs lead a discussion to resolve whether the WG should > > rebrand TLS1.3 to something else. Slides can be found @ > > https://www.ietf.org/proceedings/97/slides/slides- > > 97-tls-rebranding-aka-pr612-01.pdf. > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > > on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
On Thursday, November 17, 2016 09:12:48 pm Sean Turner wrote: > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision on > the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 In descending order of preference: 1) TLS 2.0 or TLS 2 2) TLS 1.3 3) TLS 4 There is no versioning here that doesn't have a confusion risk. Some people worry about an SSL/TLS 2.0 confusion. I worry that TLS 1.3 won't be taken with as much seriousness/urgency at a glance by those with a lower technical understanding (too many of us resort to "it's really like TLS 2" when trying to explain the leap). TLS 4 or elventybillion just forces people to answer the "what happened to TLS 3" question forever, without really making anything more clear. The confusion a big number jump tries to avoid is far better addressed by experts finally stopping with the SSL/TLS conflation. If the consensus is to keep the status quo, in spite of major changes that would normally dictate a major version bump, that's unfortunate... but the world will not implode. :/ Dave PS I suspect that a push for a major version bump a year and a half ago would've had more support, but many of us who are currently in favor of it were still in the "meh, whatever" camp. Oh well. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] COSIC's look on TLS 1.3
On Tuesday, November 08, 2016 09:55:36 am Roel Peeters wrote: > we are also wondering whether or not the Hello Retry Request will be > included or omitted in the standard. Leaving it out will make TLS 1.3 > vulnerable again to downgrade attacks ... Why are you wondering about this? HRR is in the specification and there has been no discussion to remove it. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] supported_versions question
On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote: > On 31/10/16 23:53, Dave Garrett wrote: > >> I came up with some alternative wording that I think captures the > >> discussion: > >> > >> https://github.com/tlswg/tls13-spec/pull/748 > > > > I see no reason to require servers to validate the legacy version value. > > That's just excess complexity. If the extension is there, then it should > > take absolute precedence. If not, use the old system. Nothing will have a > > higher value there except old probers. > > If legacy_version == 0x0302 (TLS1.1), but highest supported_version is > 0x0303 (TLS1.2) - or vice versa, which client_version should be used > in an RSA key exchange calculation? Why would this ever happen? What client is offering to support TLS 1.1 via the ClientHello field but offers only TLS 1.2 via the TLS 1.3 extension? This is a very contrived implementation error; if you need to account for it, abort the connection with an error. As to the vice versa, dropping 1.0/1.1 support from the extension avoids that. The simplest route here is to always use the extension if it exists, and use the legacy value if not. With 1.0/1.1 removed from the extension, that means that 1.0/1.1 cannot be negotiated with the extension, which I see as fine; they'll only be negotiated with servers that don't support the extension. (the theoretical case of a server wanting to negotiate 1.0/1.1 with a client using the extension is not one worth supporting; 1.2+ or bust is reasonable, here) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] supported_versions question
On Monday, October 31, 2016 07:26:30 pm Matt Caswell wrote:
> On 31 October 2016 at 23:13, David Benjamin wrote:
> > On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx wrote:
> >>
> >> On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> >> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
> >> >
> >> > wrote:
> >> >
> >> > > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
> >> > > > A few supported_versions questions:
> >> > > >
> >> > > > 1) What should a server do if supported_versions is received but
> >> > > > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
> >> > > > ignore legacy_version?
> >> > >
> >> > > If legacy_version > TLS1.2, the spec requires server to ignore
> >> > > legacy_version.
> >> > >
> >> > > The case where legacy_version < TLS1.2 IIRC isn't specified, but
> >> > > ignoring legacy_version is reasonable in this case too.
> >> > >
> >> > > > 2) What should a server do if supported_versions is received,
> >> > > > ClientHello.legacy_version == TLS1.2, but supported_versions does
> >> > > > not
> >> > > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail
> >> > > > the
> >> > > > handshake, use the legacy_version, or use use the versions in
> >> > > > supported_versions?
> >> > >
> >> > > There's also the case where supported_versions has TLS 1.1 and TLS
> >> > > 1.4,
> >> > > the latter the server has never heard about...
> >> > >
> >> > > > 3) If the answer to (2) above is ignore the legacy_version, and just
> >> > > > use the versions in supported_versions, which client_version should
> >> > > > be
> >> > > > used in the RSA pre-master secret calculation? The one in
> >> > > > legacy_version, or the highest one in supported_versions? Presumably
> >> > > > it has to be the one in legacy_version, otherwise thing will fail
> >> > > > when
> >> > > > the client talks to a server that doesn't understand
> >> > > > supported_versions?
> >> > >
> >> > > Yeah, I presume putting the version in legacy_version is the only sane
> >> > > thing to do. But causes other problems with downgrade protection.
> >> > >
> >> > > OTOH, RSA key exchange is known to be very broken and is affected by
> >> > > all kinds of downgrade (and other) attacks. So if one wants actual
> >> > > security, it needs to be removed.
> >> > >
> >> >
> >> > We could say the versions extension only applies to 1.2 and up. I.e.
> >> > don't
> >> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and
> >> > 1.0
> >> > when they see them in the version list. That keeps the protocol
> >> > deployable
> >> > on the Internet as it exists, avoids having to evaluate too versioning
> >> > schemes (if you see the extension, you don't bother reading
> >> > legacy_version
> >> > at all), while avoiding the weird behavior where, given this
> >> > ClientHello:
> >> >
> >> >legacy_version: TLS 1.2
> >> >supported_versions: {TLS 1.1}
> >> >
> >> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.
> >>
> >> So I guess you're also saying that a server that implements TLS
> >> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
> >> ignore the supported_versions even when it knows about it?
> >>
> >> I guess I have same questions but with only TLS 1.3 disabled, to
> >> be sure when we need to look at it.
> >
> >
> > Hrm, actually I hadn't thought of that. Yeah, I guess a server which
> > disables versions must then gate supported_version handling on whether TLS
> > 1.3 is enabled. That's not a dealbreaker, but is certainly additional
> > gnarliness.
> >
> > (Our current implementation just processes the extension uncondtionally, but
> > we'll also happily negotiate old versions out of it.)
>
> I came up with some alternative wording that I think captures the discussion:
>
> https://github.com/tlswg/tls13-spec/pull/748
I see no reason to require servers to validate the legacy version value. That's
just excess complexity. If the extension is there, then it should take absolute
precedence. If not, use the old system. Nothing will have a higher value there
except old probers.
Ditching TLS 1.0/1.1 from the extension sounds fine, though. There's not going
to be any servers accepting this extension that won't negotiate 1.2+.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New review through the TLS 1.3 Editor's Copy
On Monday, October 17, 2016 02:10:30 pm Ilari Liusvaara wrote:
> > %%% Authentication Messages
>
> > If sent by a server, the signature algorithm MUST be one offered in the
> > client's "signature_algorithms" extension unless no valid certificate chain
> > can be
> > produced without unsupported algorithms (see {{signature-algorithms}}).
>
> This is seemingly about server signatures. In that context, an
> unknown algorithm has absolutely no chance of working.
This came up in a discussion a while back and we decided to allow unsupported
algorithms as a last-ditch fall-back. Opportunistic encryption might not care
and there are systems that may trust certs as a whole, not caring about the
signatures. The end result is that the client should be tasked with making the
decision to accept or reject, not the server. Also can be helpful for debugging.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating alert levels
On Monday, October 17, 2016 01:04:18 pm Martin Rex wrote: > This list is already missing the warning-level "unrecognized_name" alert, > and such a change would imply that all new/unrecognized alerts are going > to be treated as fatal forever (i.e. that no new warning-level alerts > can ever be defined). That's already true: https://tools.ietf.org/html/draft-ietf-tls-tls13-16#section-6 https://tlswg.github.io/tls13-spec/#alert-protocol "Unknown alert types MUST be treated as fatal." Changelog says this change was made for draft 14. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#634: Registry for TLS protocol version ID
On Wednesday, October 12, 2016 07:00:34 pm Eric Rescorla wrote: > This PR involves two changes: > > 1. Attaching the term "ID" to version and defining new enum code points. > 2. Creating a registry > > The first of these seems obfuscatory and unhelpful. The second just seems > unnecessary. Other specifications other than new versions of TLS won't be > adding new code points, so I don't see how a registry helps. > > I would prefer we not merge this PR. One added feature we get with this registry definition is a range of codepoints for private experimental use. Formal definition might not be strictly needed here, though it shouldn't hurt. My reasoning for the explicit use of "ID" is that it would be more clear to use the term "version ID" to refer to the arbitrary codepoints (e.g. 0x0304) and simply "version number" to refer to the more descriptive "TLS 1.3". Both do end up on-the-wire; the former in the version fields and the later in context strings, which is one of the reasons why I think being more explicit here may be a good idea. The registry was first suggested by Daniel Kahn Gillmor in prior mailing list discussion around rebranding to TLS 2.0 (which we're treating as a separate issue, at the moment). I think it makes sense and I would prefer it be merged, but I don't ascribe very high importance here. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Industry Concerns about TLS 1.3
Mandating forward secrecy for TLS 1.3+ has been a strong consensus of this working group, so there's no point in myself or any other contributors just mass-replying with a big "no" here. That said, there is one puzzling thing I'm curious about: On Thursday, September 22, 2016 01:19:48 pm BITS Security wrote: > The impact on supervision will be particularly severe. Financial > institutions are required by law to store communications of certain employees > (including broker/dealers) in a form that ensures that they can be retrieved > and read in case an investigation into improper behavior is initiated. The > regulations which require retention of supervised employee communications > initially focused on physical and electronic mail, but now extend to many > other forms of communication including instant message, social media, and > collaboration applications. All of these communications channels are > protected using TLS. Yes, all of these other channels are protected using TLS... which you do not control in any way. Also, many sites/services already prioritize FS cipher suites, so the deprecation of plain RSA key exchange doesn't actually affect the vast majority of people. (e.g. Facebook & Twitter both prefer ECDHE with NIST P-256) Within this very argument is already the argument that supervision at endpoints is required here. The security on the pipe is irrelevant. I don't see how you can make a point to bring this up but think keeping plain RSA KE suites is a useful solution. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Cfrg] 3DES diediedie
On Tuesday, September 06, 2016 04:40:30 pm Derek Atkins wrote: > Ben Laurie writes: > > An ARM is far too much hardware to throw at "read sensor/munge data/send > > data". > > > > The question is not "how much hardware?" but "price?" - with ARMs > > including h > > /w AES coming in at $2 for a single unit, its hard to explain why you\d want > > to use a less powerful CPU... > > Because this is a light bulb that sells for $6-10. Adding $2 to the price > is just completely unreasonable. The price point needs to be pennies. > Note that this is just one example, but yes, these level of products are > getting "smarter" and we, as security professionals, should encourage > "as strong security as possble" without getting the manufacturers to > just say "sorry, too expensive, I'll go without." (which is, > unfortunately, exactly what's been happening) Personally, I'd just say "stop putting chips in light bulbs", instead. Companies making these things are unfortunately just not going to be making good security decisions. Bad or no security is cheaper than competent security, and selling light bulbs with bad security is not illegal. We'll be more successful focusing our effort on dealing with light bulb botnets than trying to get people to make secure "smart" light bulbs. There is no good solution on our end, and debating the price of chips for light bulbs is not a good way to make security decisions in TLS. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-3 in SignatureScheme
On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote: > On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara > wrote: > > I also don't see why this should be in TLS 1.3 spec, instead of being > > its own spec (I looked up how much process BS it would be to get the > > needed registrations: informative RFC would do). > > I also am not following why we need to do this now. The reason we defined > SHA-2 in > a new RFC was because (a) SHA-1 was looking weak and (b) we had to make > significant > changes to TLS to allow the use of SHA-2. This does not seem to be that case. I don't think we strictly _need_ to do this now, however I think it's a good idea given that we'll need to do it eventually and we can do it now and get people to consider implementing it more easily as part of a larger spec than later as a subsequent standalone. Doing it now gives it far greater visibility and should be relatively simple and quick to do. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Terminology clarification around SSL & TLS
On Thursday, September 01, 2016 03:17:50 pm Julien ÉLIE wrote: > There's still something I find confusing: on the one hand, SSL is badly > broken and "diediedied", it is a proprietary protocol name, and the > consensus in the TLS WG seems to be "long live TLS" but on the other > hand major SSL/TLS implementations keep the SSL name living. Arguably, renaming SSL to TLS and restarting the version numbering was a bad decision. SSL/TLS is a 21 year old protocol. It's got more than a few bad decisions in it, at least in hindsight. I too wish that major organizations would ditch the SSL naming for TLS, however until very recently many still supported SSL in some form (which is it's own problem). It is unfortunately not easy to convince everyone to update things. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SHA-3 in SignatureScheme
On Thursday, September 01, 2016 02:30:54 pm Scott Fluhrer (sfluhrer) wrote: > > On Thursday, 1 September 2016 12:43:31 CEST Benjamin Kaduk wrote: > > > On 09/01/2016 12:38 PM, Hubert Kario wrote: > > > > The SHA-3 standard is already published and accepted[1], shouldn't > > > > TLSv1.3 include signatures with those hashes then? > > > > > > Why does it need to be part of the core spec instead of a separate > > document? > > > > because: we also are adding RSA-PSS to TLSv1.2 in this document, I don't see > > why it needs to be delayed. Finally, TLSv1.2 added SHA-2 just like that, it > > was > > not tacked on later. > > IIRC, SHA-2 was a special case; SHA-1 was demonstrated to be > cryptographically weaker than expected and so we needed to have a secure > alternative ASAP. > > The SHA-3 is not like that; there's no evidence that suggests that SHA-2 is > weak; the only incentive to implementing SHA-3 is "we'll, it is a standard, > and so we might as well support it". The reason I see is that we currently specify exactly one valid hash algorithm (in a variety of sizes). The precedent argument is good enough for me. I think adding it in this document is definitely worth considering. I don't want to wait until SHA-2 is considered weak to provide an alternative, if we can avoid it. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
On Thursday, September 01, 2016 02:05:25 am Judson Wilson wrote: > > I like TLS/2 aesthetically, and represents a similar level of > > progress/reset that HTTP saw when it jumped from 1.1 to /2. > > What is the slash in the name all about? Is it simply playing off the HTTP > start line specification? Does it have any relevance to TLS? Did this slash form start with HTTP/2, or was there some other progenitor? Why did they go with that, anyway? I just find it to be a weird choice. If we actually have a consensus that it'd be better to go with TLS/2 than TLS 2.0, officially, I'd only be ok with it if someone can actually explain why. :| Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
On Wednesday, August 31, 2016 06:42:28 pm Erik Nygren wrote: > Is it worth having a poll (hate it, neutral, love it) on options to judge > preference > It seems like options are (I may have missed some): > > - TLS 1.3 (ie, the default if we do nothing) > - TLS 2.0 > - TLS 2 > - TLS/2 > - TLS 4.0 > - TLS/4 > - TLS 4 > - TLS 34 > > On the topic of "what does this re-open", I'm not convinced it does. > The concept of doing a rename shortly before the last call goes way back > and has been correctly deferred as bike-shedding until now. > What color do we want our bike shed? A few of us have specifically had discussions with people about how "TLS 1.3 is really TLS 2.0"; just relabeling it that should be fine. We risk over-complicating things by doing a number jump a la Windows 10. I don't particularly want to have to answer the question "what happened to TLS 3?" for the next decade or so. To repeat what I said in a previous reply, I think TLS 2-2016 or something is an ok way to reference things (outside of the spec doc). Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
On Wednesday, August 31, 2016 06:35:13 pm Nick Sullivan wrote: > I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I was too, until we created a new cipher suite negotiation incompatible with previous versions. > I see a few immediate issues with the proposal: > - it causes confusion with SSL 2.0 I disagree. There is a perpetual confusion between SSL and TLS, but this doesn't really make it that much worse. > - it implies wire incompatibility with TLS 1.2 SSL 3.0 and TLS 1.0 share compatible hellos. A TLS 2 only client won't be able to connect to a TLS 1.2 only server, but that's true with all version changes. I don't see how a major version bump implies any more wire incompatibility, especially when we bend over backwards to maintain hello compatibility with SSL 3. > - it suggests there will be a forthcoming TLS 2.1 with only minor changes There could be, if we wanted to. I don't see a problem with that. > If we're dead set on bumping the major version for a mostly backwards > compatible protocol change, we should just drop the minor version and go > with TLS/2. I don't have a problem with dropping the ".0", but I don't see the point in the HTTP/2 style slash. TLS 2 is fine. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0
I've updated my WIP based on feedback and submitted it as a PR here: https://github.com/tlswg/tls13-spec/pull/612 If anyone else catches another spot that needs some updating, please comment on the PR. As this is a rather notable change, I do propose this remain open for discussion for at least a week or so before the chair assesses consensus. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Terminology clarification around SSL & TLS
On Wednesday, August 31, 2016 12:44:02 pm Daniel Kahn Gillmor wrote: > i would like to continue to be able to say unambiguously that all known > versions of SSL are badly broken and should be avoided. Let's not muddy > those waters further. +1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
(replies to 4 separate but related posts, below) On Wednesday, August 31, 2016 03:52:44 am Peter Gutmann wrote: > Julien ÉLIE writes: > >Considering that possible change, wouldn't it be useful to go on working on > >draft-gutmann-tls-lts-05, and consider TLS-LTS not as a TLS extension but as > >a real 1.3 version of the 1.x series? > > If the current 2.0-called-1.3 is renamed to 2.0, I'd be open to calling LTS > "1.3", although I think it's more a 1.2.1 :-). Its real goal though is to be > exactly what it says on the label, an LTS version of the TLS 1.x line that can > be used in devices with long lifecycles that are based on the 1.x family and > need a best-of-breed version of that. So LTS would be the final, wrap-up > version of the 1.x line for people who need, well, an LTS version of the > protocol. You can't really do that. The HTTP/2 spec explicitly refers to TLS 1.3 and up as not needing the security restrictions on TLS 1.2 it lays out. Any TLS 1.2 LTS will need to be 1.2.x to deal with old documents citing the draft. (there's also citations of analysis of TLS 1.3 that reference it) On Tuesday, August 30, 2016 05:21:21 pm Daniel Kahn Gillmor wrote: > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml > doesn't have a "TLS version" registry. Would it be simpler to have IANA > create that and just populate it with: > > Value | Description | Reference > --+-+-- >0x30 |SSLv3| RFC 6101, RFC 7568 >0x31 | TLSv1.0 | RFC 2246 >0x32 | TLSv1.1 | RFC 4346 >0x33 | TLSv1.2 | RFC 5246 >0x34 |TLSv4| RFC I've already dropped the struct major/minor labels and changed the type to just uint8x2 in my draft of this proposal. Explicitly adding a registry to go with this sounds good to me. On Wednesday, August 31, 2016 05:35:47 am Xiaoyin Liu wrote: > It's normal that people confuse SSLv3 with TLS. SSL 3.0 was a released and > widely deployed protocol, and the term "SSL" is still widely used today to > refer to TLS.[...] "Normal" people have no clue what SSL or TLS is. Personally, I say that anyone saying "SSL" should be interrupted by saying "SSL is dead, long live TLS". All of SSL has been diediedied, so it's a reasonable cutoff point to support expectations for the moment, at least. SSL/TLS is a mess of over 20 years of stuff; we can't clean it up fully, but we can try to make it a little more clear. ;) On Wednesday, August 31, 2016 04:47:59 am Hubert Kario wrote: > if the WG really wants a TLSvX.0 name, the X really should be bigger than 3 We can call it TLS-2016 in addition to 2.0, which could help with some people, but doing the disjoint versioning thing is not a good idea, IMO (and a fair portion of the WG seems to be notably against it). I don't want to do a confusing thing to try to mitigate another confusing thing. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
On Tuesday, August 30, 2016 02:36:51 pm Xiaoyin Liu wrote: > I support this change as long as there is no technical change (version ID > remains 0x0304). To reiterate, I am also against changing the version ID. However, I do think it's worth updating the context string version number, otherwise it'd be a little unnecessarily confusing there. (trivial change to key derivation, but not wire format) I've also made a point to tweak references to the on-the-wire version value to refer to it as a "version ID" rather than just version, to make it very clear that this is really just an arbitrary codepoint and shouldn't be read as 3.4. I've made the changes for a WIP branch, here (not a PR, as of yet): https://github.com/tlswg/tls13-spec/compare/master...davegarrett:tls2rebranding Going through the motions of doing the renaming now is useful to see if there's anything that is more affected than initially expected, such as the context strings having the version in there directly as a string (they're designed to be updated as-needed, so this shouldn't be a problem). Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS 1.3 -> TLS 2.0?
I occasionally see people ask why we're calling it TLS 1.3 when so much has
changed, and I used to simply think that it was too bikesheddy to bother
changing at this point. However, now that we've redone negotiation, we have new
TLS 1.3+ only cipher suites. The old are not compatible with the new (new
codepoints needed for old ciphers) and the new are not backwards compatible
with the old (they'll just be ignored). We actually risk misconfiguration in
the future if the distinction isn't made clear. I think it's time we just
renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a major
version seems more appropriate.
Note that contrary to what some people seem to think, version numbers are not
completely without meaning. To someone who doesn't really know/care that much
what TLS is, making sure to use the latest major version of a security protocol
carries more weight than a minor version. It also makes it clear that there are
new features here (e.g. 0-RTT). There's some de facto standardization in
versioning which does carry some useful information. We're not just dealing
with programmers here; this stuff needs to be clear for managers and
non-professionals. If we want to get everyone upgraded eventually, messaging is
important.
Specific proposed changes:
* Mass rename TLS 1.3 to TLS 2.0 in all places (or TLS 2)
* Keep the version ID as { 3, 4 } (already weird counting; changing risks more
intolerance)
* Rename the new cipher suites to have a "TLS2_" prefix to be less confusing
for the registry & end configuration
* Add a sentence noting the development history here, and that all documents
that refer to TLS 1.3 refer to TLS 2.0 (e.g. HTTP/2)
This is a relatively simple set of changes to make that I think can be
beneficial in the long run, and is essentially just editorial. Rebranding might
not be something everyone really wants to bother with, but if we expect this to
be in use for a decade or more (whether we like it or not), we should probably
make sure to be as clear as possible at the start.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] (confusing the issues) Re: [Cfrg] 3DES diediedie
Within this line of thought, an unlimited-key-use-diediedie would have far more value. An RFC precisely defining a set of key data limits would address both this 3DES issue as well as AES and any other cipher. As cited on https://sweet32.info/ , data limits is a primary way Mozilla is dealing with this attack. Dave On Monday, August 29, 2016 09:26:18 am Rene Struik wrote: > I think it is a mistake to think that simply using block ciphers with a > larger block size is enough to counter attacks, as the literature on > successful side channel attacks on such block cipher demonstrates. The > real message is that one should not reuse keys ad infinitum, which > unfortunately seems hard to sink in. > > Singling out 3-DES in this respect does not seem to tackle the real > issue (which is a system security issue often only paid lip service to > in practice). > > Rene > > On 8/29/2016 8:56 AM, Joachim Strömbergson wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Aloha! > > > > As a side note, there has been a bunch of lightweight block ciphers > > suggested the last few years, most of them with a block size of 64 bits. > > And there has been discussion on IETF maillists about IETF accepting > > them. For example the SIMON and SPECK ciphers. These ciphers can have > > block sizes as small as 32 bits. > > > > https://www.cryptolux.org/images/a/a0/Beaulieu-DAC2015.pdf > > https://eprint.iacr.org/2015/209.pdf > > > > Yours > > JoachimS > > > > > > > > David McGrew (mcgrew) wrote: > >> Hi Peter, > >> > >> You make a bunch of good points. But it is also worth noting that > >> some people feel that current crypto standards, including IETF > >> standards, are suitable for IoT. See for instance slides 8 and 9 of > >> Daniel Shumow's talk at NIST’s LWC workshop last year: > >> http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf > >> Also, CoAP isn’t on his list, but it could be, and it uses DTLS. So > >> while I agree with you that overuse of a 64-bit block cipher is far > >> from the biggest security concern for IoT, the IETF should expect its > >> protocols to be used in some IoT scenarios. > >> > >> The malleability of the term IoT is causing trouble here. Slide 6 > >> of Daniel’s talk is quite revealing. To my thinking, by definition > >> IoT devices are connected to the Internet in some way. > >> > >> David > >> > >> > >> > >> On 8/28/16, 8:01 AM, "Peter Gutmann" > >> wrote: > >> > >>> David McGrew (mcgrew) writes: > >>> > I don’t think you understood my point. IoT is about small devices > connecting to the Internet, and IETF standards should expect > designed-for-IoT crypto to be increasingly in scope. It is > important to not forget about these devices, amidst the current > attention being paid to misuses of 64-bit block ciphers, which > was the ultimate cause of this mail thread. > >>> But the IETF has a long history of creating standards that > >>> completely ignore IoT. I can't think of a single general-purpose > >>> IETF security standard (TLS, SSH, IPsec, etc) that has any hope of > >>> working with IoT devices (say a 40Mhz ARM-core ASIC with 32kB RAM > >>> and 64kB flash). This is why the ITU/IEC and a million > >>> lesser-known standards bodies are all busy inventing their own > >>> exquisitely homebrew crypto protocols, most of which make WEP look > >>> like a model of good design. > >>> > >>> (I've always wanted to sit down and design a generic "encrypted > >>> pipe from A to B using minimal resources" spec, and I'm sure many > >>> other people have had the same thought at one time or another). > >>> > >>> So it seems like you've got: > >>> > >>> - The "TLS = the web" crowd (browser vendors and the like) who will > >>> implement whatever's trendy at the moment and assume everyone has a > >>> quad-core 2GHz CPU with gigabytes of RAM and access to weekly live > >>> updates and hotfixes. > >>> > >>> - Embedded/SCADA folks who need to deal with 10-15 year product > >>> cycles (see my TLS-LTS draft for more on this) and are kind of > >>> stuck. > >>> > >>> - IoT people, who can't use any standard protocol and will get the > >>> least unqualified person on staff to invent something that seems OK > >>> to them. > >>> > >>> I'm not sure that a draft on theoretical weaknesses in 64-bit block > >>> ciphers is going to affect any of those... ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Thoughts on Version Intolerance
On Thursday, July 21, 2016 06:42:52 am Hubert Kario wrote: > On Wednesday, 20 July 2016 19:30:27 CEST Martin Rex wrote: > > Any ClientHello with > 200 Cipher suite code points indicates fairly insane > > Client behaviour, so rejecting it is _perfectly_sane_ server behaviour. > > and which part of the standard says that it is "_perfectly_sane_" server > behaviour? On this specific type of issue, I agree with Martin here that sanity checks for over-the-top configurations are reasonable, however we should be standardizing this, not having every implementation do this ad hoc. We really should go through a list of these sort of implementation break points and start picking arbitrary lines to add to the spec. They don't have to be ideal numbers; just something better than an upper limit of 2^15-2 suites (2 bytes each; 2^16-2 max sized vector) would be nice, for this example. Yes, certain fields have to stay open-ended, namely extensions, but reasonable limits should be added where appropriate. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Refactoring the negotiation syntax
On Wednesday, July 13, 2016 01:12:54 pm Eric Rescorla wrote: > The basic idea here is to factor out the TLS 1.3 negotiation into three > mostly orthogonal axes. > > - Symmetric cipher/PRF -- indicated by the cipher suite list as in TLS 1.2 > - Key exchange -- indicated by the key_shares and pre_shared_key extensions > - Authentication -- indicated the signature_algorithms and pre_shared_key > extensions > > A proposal for how to do this is below. See the end for other options, > caveats, etc. > > > If we take PSK out of the picture, this gives us a very simple structure: > > - The client offers a set of key_shares and the server picks one that it > likes [1]. > - The client offers a list of signature_algorithms and the server picks > a certificate/key that matches that list and signs with it. Your proposal ignores the supported_groups extension. The requirement of this is one of the wrenches that causes the complexity of this whole system to increase. HelloRetryRequest is the other wrench here. We very much could do everything supported_groups does in key_share; just stick unsent supported groups in the share with null keys. The desire to maintain backwards compatibility with a different mechanism using the old version of supported_groups is what makes this a problem. (back compat is not free) As to the PSK side of things, one idea which I brought up at some point is to merge the PSK extension into the key share extension to create one unified key exchange extension. We just assign some group ID to PSK, then the identity is just its equivalent of a key to be in the bag of keys. One less new extension to worry about, and instead one new extension that is 100% required for all TLS 1.3 requests, without exceptions that might need to be handled. (blending into the other current list thread, here) The special handling of PSK is another one of these metaphorical wrenches that increases the design complexity in various places. As to the actual core proposal, it could work. I too am not ideally in favor of redoing everything at this late stage, but I'm not against reconsidering it, if we can all actually agree on an alternative. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Server-side missing_extension MUSTs
On Wednesday, July 13, 2016 01:01:13 pm Eric Rescorla wrote: > It's natural to pick the cipher suite first and then look for the key_share > extension, so if, for instance, you pick a PSK-only cipher suite, then you > wouldn't look for the key_share. Agreed. That's why I'm ok with the current "no alternative cipher suite is available" qualification. If the extension never comes up, then not giving a specific error for it is allowed. On Wednesday, July 13, 2016 10:43:58 am David Benjamin wrote: > To be clear, I am not at all opposed to useful errors or strict policing of > what the peer sends. [...] > Complexity is the currency we pay for adding things. I very much agree. Our debate hinges on risk assessment, which gets admittedly hard when talking about unknown future implementations. ;) Essentially, the design philosophy I and Hubert are advocating involves mandatory validation of inputs by all implementations such that we focus on avoiding divergence from what we all agree to in the spec, rather than always try and use our imagination to enumerate each individual screw up that could be made. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Server-side missing_extension MUSTs
On Wednesday, July 13, 2016 01:23:53 am David Benjamin wrote: > I'm also curious what cases were you envisioning missing_extension to be > useful. I spend a lot of my time triaging TLS-related bugs in Chrome, so > I'm certainly not blind to TLS handshake errors being difficult to > diagnose, especially on the client. But I don't believe such an alert would > ever have helped me. Perhaps I am missing something? I've triaged TLS-related bugs in Firefox (to be fair, not as much as of late), which largely made me come to the conclusion that stricter and more precise error handling is sorely needed. I make no claim that this particular error in this particular case is the focal point on which anything practical I can come up with at the moment hinges, however I have seen too much nonsense to not advocate for rigorous preventive action. When we leave holes and generic responses in specs, the incomprehensible litany of implementations inevitably results in interactions that we are not capable of predicting. To be clear though, completely mandatory extensions, at least as we're doing them here, are a new thing. TLS 1.2 relied on separate messages for stuff, but we're front-loading everything into the ClientHello to get reliable 1RTT (with the exception of HRR). > I don't believe an implementation which fails to send supported_groups, > etc., in 1.3 would ever leave a developer's workstation. It would not > interoperate with anything. Such a client is completely failing to > implement the protocol, and in a way that nothing would work. We have to assume that some small minority of implementors are not acting in good faith to maintain ideal security, but rather are creating something just functional enough for their specific purpose (possibly a larger minority with IoT). If someone kludges an ad hoc client/server pair that skips the groups extension to go straight to key share, they could get it to work fine. (they're only separate because we are, ourselves, kludging in new features into an old extension, whilst maintaining backwards compatibility) If someone else then has to get this to work with a normal server, they're going to have to let this slide. It is a hell of a lot easier (from a psychological & political perspective) to just kludge in a special case instead of being forced to explicitly cancel out error checks/reporting that come directly from the spec. The more this stuff is left unspecified, the more risk we get of kludge-related breakage/exploits. As a rule, I never assume something is impossible; you can always be surprised by the interactions of several kludges and a few lazy, sloppy, stupid, or malicious people. This is a 20 year old mess; paranoia is required. > If we wish to address the diagnosis problem, we should think about those, > and also how to simplify negotiation so the kinds of errors are less > complex and reporting them is simpler, rather than get distracted by > trivialities. I agree we should simplify negotiation, wholeheartedly. That is most certainly a better way to do things. I preferred we just require groups and key share for all TLS 1.3+ hellos, always, without exception. Much simpler, but pure-PSK (which I'd prefer was not in the spec) is the special case that complicates things here, and merging the two systems into one simpler one was rejected. (one always mandatory dh/psk key specification extension that is always used requires far less thought to sanity check) Just because a better system isn't used, doesn't mean I won't advocate for stop-loss on what we do go with, however. To restate what I said in my other reply, downgrading the relevant MUSTs to SHOULDs would be something I'd be ok with. Servers MUST give an appropriate error when aborting, and SHOULD give the most relevant one they can provide at that time. I do not claim that this here specifically is of top-tier importance, but I will generally resist all attempts to water-down constraints we had previously maintained consensus for. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Server-side missing_extension MUSTs
On Tuesday, July 12, 2016 10:51:22 pm Eric Rescorla wrote: > I generally agree with David here. > > -Ekr > > P.S. Back in Seattle, we had rough consensus to change the alert requirements > [0] so that > you didn't have to send alerts, but if you sent an alert, you had to send > alert X. That's been > on the TODO list for a while but expect a PR soon. > > [0] https://github.com/tlswg/tls13-spec/issues/254 I am aware that discussion ended up on accepting sloppy error reporting as acceptable. Changing the disputed missing_extension alerts to SHOULDs would be an acceptable compromise if that decision is still actually going through. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Server-side missing_extension MUSTs
On Tuesday, July 12, 2016 09:58:46 pm David Benjamin wrote: > I would like to remove the missing_extension MUSTs on the server side. Full > justification in the PR. > https://github.com/tlswg/tls13-spec/pull/544 > > On the client, it is perfectly feasible to mandate a particular alert > value. The check is very straight-forward. On the server, however, this is > a mistake. Servers do not necessarily have full information if not all > advertised ciphers are known, and a natural implementation of the > negotiation algorithm will not output this case. Even without this clause, > the handshake is already required to fail, so there is no risk of invalid > clients being deployed. > > Adding more complexity to an already hairy negotiation algorithm (the > pseudocode I mentioned is incomplete) just to diagnose what is an invalid > ClientHello anyway is not worth it. It buys too little for the complexity > cost. Reporting errors sufficiently is not an inconsequential issue. TLS has many interop issues with servers which just stare blankly back when something goes wrong, or fail in ways which do not indicate why. This general topic has come up as a problem in discussions here before. We need to specify how to fail appropriately such that when it happens, it can actually be diagnosed and fixed easily. The alternative is people sticking with the status quo forever. The only way this adds complexity is if you assume you're only writing the client and server for themselves, not expecting to interop with unknown peers. First of all, as to not having "full information", I don't think anyone expects a server to be expected to pick the exact error alert if it can't even parse the cipher suites in question. When a server just skips over an unknown suite, if a missing_extension was technically correct for a server which could've understood it, then it doesn't really matter; the lack of that extension isn't what's causing the failure, as it never gets to that point. To respond to your pseudocode in the PR, I'd say that explaining the expectation is simpler with a try/catch model: just assume that the required extensions are present, do whatever you do, and throw a missing_extension exception to trigger said fatal alert if at any point that fails to be true. (if you're using a language that does not have exceptions, you can of course do the same thing, just differently; this model just makes stating things simple) The current wording in the draft has "and no alternative cipher suite is available" added in there, as selecting another suite that doesn't care about such a fault was agreed to be passable because requiring further validation after an acceptable suite+variables was already found was agreed to be excessive. However, we do not mean to imply that you should go _looking_ for an alternative if you're evaluating a suite and the required extension for it is missing. I would generally advise against adding workarounds for implementation flaws you've yet to actually encounter, as all you do is make it harder to detect and fix them when first created. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
Just replying to a few points.
On Tuesday, July 12, 2016 12:16:24 am Ilari Liusvaara wrote:
> ### Hello Retry Request
>
> > selected_group
> > : The mutually supported group the server intends to negotiate and
> > is requesting a retried ClientHello/KeyShare for.
> > {:br }
>
> What is written into this field if server selects pure-PSK ciphersuite
> and then decides to reject the ClientHello? Or connections that use
> pure-PSK just plain can't be rejected for any reason (including IP
> address verification in DTLS?)
The HelloRetryRequest message is not applicable to pure-PSK, which does not use
the KeyShare extension at all. PSK has its own separate extension. ((EC)DHE-PSK
uses both together)
The purpose of HelloRetryRequest is to allow for clients to not send full keys
for every single algorithm they support, yet allow the server to still pick
from that entire list if it needs to. PSK has no equivalent system; pre-shared
keys are first-flight or bust. If an (EC)DHE-PSK suite is selected, and a valid
PSK identity is selected, the server can use HelloRetryRequest to reject a
group in favor of another supported by the client, but it can't reject the
suite or identity in this manner. The response to no acceptable PSK identity is
either to negotiate another suite or to abort with a fatal alert.
See draft 14 section 4.2.5:
https://tools.ietf.org/html/draft-ietf-tls-tls13-14#section-4.2.5
> > ## Cipher Suites
> >
> > Note: The values listed for ECDHE and ChaCha/Poly are preliminary but
> > are being or will be used for interop testing and therefore are likely to be
> > assigned.
>
> Isn't the RFC already published, so the codepoints are stable?
xiaoyinl fixed the second one of those notes, but that was merged after the
checkpoint for draft 14. I'll fix this one to just note for ECDHE PSK AES.
> > ## Implementation Pitfalls
> >
> > - Have you ensured that all support for SSL, RC4, EXPORT ciphers, and
> > MD5 (via the "signature_algorithm" extension) is completely removed from
> > all possible configurations that support TLS 1.3 or later, and that
> > attempts to use these obsolete capabilities fail correctly?
> > (see {{backward-compatibility}})
>
> Better to just nuke the code entierely for all versions.
>
> "Disabled" code has nasty tendency of coming back to life.
Emphatically agreed, however I worded it this way to be slightly more general.
If I said that all that code should be universally gutted, I'd risk more people
ignoring it due to the severe status quo bias that is very common. In lieu of
modernizing fully and dropping it completely, having these old features
disabled via the same compile-time option that enables building of TLS 1.3
would be acceptable, IMO (though, more trouble than it should be worth, and
still not ideal at all). Bikeshedding better wordings in this section would not
be unwelcome, if you think anything here can be made better.
> > - Do you handle TLS extensions in ClientHello correctly, including
> > unknown extensions or omitting the extensions field completely?
>
> The extensions field can't be omitted in TLS 1.3. And I would
> consider TLS 1.2 client implementations that send such messages
> as quite pathological.
Implementations should be expected to handle pathological cases gracefully,
even if only to recognize and reject. ;)
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Reminders
On Monday, July 11, 2016 10:27:21 am Sean Turner wrote: > - Before 12 July, we’d like to know your thoughts about progressing > draft-ietf-tls-pwd (Watson and ekr responded): > https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4 This document defines new cipher suites using obsolete crypto. Quoting https://tools.ietf.org/html/draft-ietf-tls-pwd-07#section-5 : > This memo adds the following ciphersuites: > > CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD ); > > CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); > > CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); > > CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); > > Implementations conforming to this specification MUST support the > TLS_ECCPWD_WITH_AES_128_CBC_SHA ciphersuite; they SHOULD support > TLS_ECCPWD_WITH_AES_128_CCM_SHA, TLS_FFCPWD_WITH_AES_128_CCM_SHA, > TLS_ECCPWD_WITH_AES_128_GCM_SHA256, > TLS_ECCPWD_WITH_AES_256_GCM_SHA384; and MAY support the remaining > ciphersuites. Most of those should not be defined in any new document approved by this WG, let alone one based on a low entropy secret. In particular, the SHA1 suites shouldn't be there, and the CBC suites should be scrapped as well. The spec allows for these suites to be negotiated with TLS 1.0-1.1 (hence the CBC), which should just be dropped to focus on TLS 1.2 & TLS 1.3+. The MTI is not even supported by TLS 1.3. Don't define new crypto systems using obsolete crypto systems. I don't see how we could expect any implementations that don't even support TLS 1.2 to implement something new like this, anyway. If this draft moves forward in any way, it should be reduced to AES 128/256 GCM/CCM, with possible addition of a ChaCha/Poly suite. Quoting https://tools.ietf.org/html/draft-ietf-tls-pwd-07#section-1.1 : >1.1. The Case for Certificate-less Authentication > > TLS usually uses public key certificates for authentication > [RFC5246]. This is problematic in some cases: > > o Frequently, TLS [RFC5246] is used in devices owned, operated, and > provisioned by people who lack competency to properly use > certificates and merely want to establish a secure connection > using a more natural credential like a simple password. The > proliferation of deployments that use a self-signed server > certificate in TLS [RFC5246] followed by a PAP-style exchange over > the unauthenticated channel underscores this case. [...] If we're setting up new systems to lower the barrier to entry, ACME is the way to go, not this. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS client puzzles
On Wednesday, July 06, 2016 04:23:23 pm Hannes Tschofenig wrote: > (And note that I am not saying that IoT devices aren't used for DDoS > attacks.) For that matter, I feel like IoT is a larger DDoS risk in the long-term than other arenas. A botnet of bazillions of little widgets with Internet access and no updates and distributed widely would be an even greater PITA to deal with than we've had in the past. IoT being currently incapable of attempting to use this system almost feels like a feature, rather than a bug. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] judging consensus on keys used in handshake and data messages
On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote: > I'm also curious which post-handshake messages are the problem. If we were > to rename "post-handshake handshake messages" to "post-handshake bonus > messages" with a distinct bonus_message record type, where would there > still be an issue? (Alerts and application data share keys and this seems > to have been fine.) Recasting all the post-handshake handshake messages as not something named "handshake" does make a degree of sense, on its own. (bikeshedding: I'd name it something more descriptive like "secondary negotiation" messages or something, though.) Even if this doesn't directly help with the issue at hand here, does forking these into a new ContentType sound like a useful move, in general? Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] More hello entropy? (was: PR 508: Move downgrade sentinel to end)
On Sunday, July 03, 2016 07:02:05 pm Eric Rescorla wrote: > This seems reasonable, as the > only real argument against is that conformant TLS 1.3 servers will have > only 20 bytes of entropy when doing TLS 1.2 compat (if they put the time in > the top 32 bytes), as opposed to 24 if they randomize the first 32 bytes. to correct the typo: 32 bits / 4 bytes; total size of random is 32 bytes / 256 bits > OTOH, those bytes will be more unique over time (because they are > guaranteed not to repeat for a very long time after the second has passed), > so intuitively this seems like a wash. Under the "Reevaluate handshake contents" part of the current TLS WG charter [0], we have the question: "Are bigger randoms required?". Did the WG ever fully discuss this and come to a decision? Adding a supplemental entropy extension would be trivial, if we wanted to do so. (I see there was consideration of doing so a while ago [1].) Amending the TLS 1.3 spec to add it as a requirement would be easy, but would it be useful? If we want to allow 2 hacks in the current random value that reduce the entropy, then adding some entropy back in an extension makes some sense. (If this was already settled at some point, please just point me to wherever that was. I might've just forgotten. ;) Dave [0] https://datatracker.ietf.org/wg/tls/charter/ [1] https://tools.ietf.org/html/draft-rescorla-tls-extended-random-02 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
On Monday, June 20, 2016 08:39:11 pm Eric Rescorla wrote: > Nobody seems super-excited about either Option 1 or Option 2, so it's > at least worth noting that there's one of the options I claimed was > rejected earlier, namely separately encrypting the content type in > roughly the manner suggested by DKG, Ilari, and Kenny. Thanks for > Doug/Felix for prompting me on this. > > > NOTE: I don't promise any of the below is secure, though it probably > can be made so with enough work. Actually doing so is an exercise > for the reader. > > > The basic idea is as follows: > > 1. In each direction generate a separate "content_type_key" > 2. Separately encrypt the content type from the rest of the record >using the content_type_key. > 3. On the receiving side, first decrypt the content type and then use >that to determine what key to decrypt the record. > > The trivial version of this is just to AEAD encrypt the content type > separately, but this has unacceptable bandwidth and CPU properties, so > is probably not viable. However, there are more efficient designs, > which can get the overhead down to modest levels (<= 1 byte of > expansion and <=1/16 of a block computation/record). > > The obvious construction is to use the content_type_key to compute a > per-record masking value (effectively an ad hoc stream cipher) and > then use that to encrypt the content type (or potentially just a key > type bit) without integrity (though you might later protect it in the > additional data block under the main key). This gives you an > encryption function without expansion. If you have a mask function > which outputs one block at a time, you can use pieces of the block for > each record (e.g., for record N you use byte N/16) [1] > > > Obvious objections to this: > 1. This isn't integrity protected. This is probably the most serious > complaint and has the potential to actually leak information about > the content type unless you're careful [2], even if you eventually > integrity protect this information. > > 2. It's odd to just use a piece of the AEAD cipher (the encryption > function), especially if we ever had a really non-composite cipher. > This can be alleviated by using HKDF-Expand to produce the stream > of bits. > > 3. Maybe it doesn't get the whole job done, especially wrt the fact > that we're not rekeying the app data after client auth. > > 4. It's gross. Yes, yes it is. > > > I'm not really in love with this idea, but I did want people to know > that maybe we don't *have* to choose between option 1 and option 2 > in case that changes people's opinions. All this complexity for encrypting a single bit seems like way too much of a risk. An idea for an option 4: Keep typing and keying as it currently is (as of draft 13), but mandate a KeyUpdate immediately following (and/or before) non-application traffic. We already have a mechanism to use different keys in series, which sounds like it might be simpler than trying to figure out a good way to do so in parallel. Is this a viable thought to pursue, or does this still not help enough with our key separation worries? An additional thought might be adding a random to KeyUpdate to make the new key not based entirely on the old entropy. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
On Tuesday, June 14, 2016 04:37:09 am Martin Thomson wrote: > On 13 June 2016 at 21:27, Daniel Kahn Gillmor wrote: > > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: > > > 1. Use the same key for handshake and application traffic (as in the > > > current draft-13) > > > > > > or > > > > > > 2. Restore a public content type and different keys > > > > Given this choice, i prefer (1). > > +1 > > However... > > I confess that I still haven't properly internalized the objection > from the cryptographers, and that means that I could probably live > with a public content type if more convincing evidence for the value > of 2 could be produced. +1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]
On Tuesday, June 07, 2016 05:08:00 pm David Benjamin wrote: > On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir wrote: > > > On 7 Jun 2016, at 8:33 PM, Hubert Kario wrote: > > > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: > > >> I’m not sure this helps. > > >> > > >> I’ve never installed a server that is version intolerant. TLS stacks > > >> from OpenSSL, Microsoft, > > > > > > are you sure about that Microsoft part? > > > > > > there is quite a long thread on the filezilla forums about TLS version > > > tolerance in IIS: > > > https://forum.filezilla-project.org/viewtopic.php?f=2&t=27898 > > > > That’s surprising. > > > > The last time I tested with an IIS servers it was Windows Server 2003 and > > 2008. They did not support TLS 1.2, so I wanted to check if they could > > tolerate a TLS 1.2 ClientHello. They did. Of course, they replied with TLS > > 1.0, but that was expected. > > > > It’s strange that this behavior would degrade for much newer versions of > > Windows that came out at a time where several browsers were already > > offering TLS 1.2. I wonder if it’s just the FTP or also IIS. > > This is the first I've heard of this and I believe neither Chrome nor > Firefox accept TLS 1.2 intolerance and below anymore. To my knowledge, that > has successfully been driven out of the ecosystem. ;) Driven out of the higher traffic mainstream ecosystem, maybe, but there will be a long tail of junk servers that stay around for entirely too long (read: "forever"), in spite of current versions of clients not accepting it anymore. My tracking meta-bug in Mozilla's Bugzilla may have finally been closed last month, but that's just tickets filed by people who can actually get a report into the thing. Most people just see such brokenness as the browser's fault and switch to any (older) browser with compatible brokenness, and to any of us they're invisible. The non-trivial population of servers that are TLS 1.0-1.2 version tolerant but not TLS 1.3+ version tolerant is a far more worrying problem, though. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt
On Tuesday, June 07, 2016 03:57:32 pm Ted Lemon wrote: > The point of the different result codes is to give the end-user some basis > for figuring out why they didn't get to the site. "Malicious site" is > different than "policy violation." A malicious site is a site that serves > malware, or does phishing, or typosquatting, or something like that. > Policy violation could be "no facebook during business hours." Policies > are typically under user control, so being able to know that you can do > something to address the problem is key. I think the problem that we would want to stress here is that there are far too many places where things that people just don't like get treated as "malicious" and policies are created to block them. The difference between the two is valid, but I have no faith whatsoever that people can really rely on them being properly labeled and communicated. As far as I'm concerned, the determination of explicit designation as malicious is up to the client and any sort of its _own_ content blocking, not anything on the network. As such, I feel like these two alerts can't safely be considered separate. One alert simply for all prohibited connections, without trying to explain human reasoning in one bit of information, would be preferable. Likewise, I don't immediately see why captive portals are sufficiently different from the account attention requested/required cases to warrant separate designation. Upon reading the draft, my first impression is that a set of 3 codes (preferably named more akin to: network_prohibited_connection, network_account_reqested, network_account_required) instead of the current 5 would be more appropriate, and even then, the please/maybe/whatever nature of the second one seems a little odd to me. Just the two "nobody allowed ever" and "you're not allowed (yet)" alerts are the only ones I see particularly convincing justification for. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
On Monday, June 06, 2016 06:48:20 am Hubert Kario wrote: > What makes you think that a new version negotiation that works more or > less in the same way will _not_ be implemented incorrectly? The list-based extension doesn't work in quite the same way. The current mechanism compares two values and picks the lower one. This new mechanism compares two lists and picks the highest mutually listed. Also note that I wish to officially drop any meaning from the version IDs such that we're using an arbitrary 16-bit serial number rather than two 8-bit major & minor numbers. The new supports discontinuous lists, e.g. support of 1.0, 1.2, & 1.4, but not 1.1 or 1.3, without risking accidental negotiation of a lower version that isn't desired. (if 1.3 is eventually declared less ideal than 1.2 or 1.4 due to some unforeseen problem, this gives us a safe mitigation, and it extends to arbitrary future scenarios) Also, as with any new system, we now have the ability to loudly stress to TLS 1.3+ implementers to not screw it up and test for future-proofing this time around. At a minimum, implementations will not be able to use the exact same code to negotiate in both systems and would have to go out of there way to add intolerance stupidly, rather than stumble into it stupidly again. Just sticking a new field in an extension lets implementers route it into the same code and risk the same mistakes; adding a bit of complexity here is an unfortunate cost of fixing this mess. Just adding a new _empty_ extension, as was more recently proposed, is something I think could also work ok. Again, if we're more likely to get consensus on that, I think it's viable too. The idea of a compliance test suite has come up before and I will again say: YES, PLEASE! I certainly don't claim anything proposed here is perfect, but nothing is or will be in a 20 year old protocol. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Closing on keys used for handshake and data messages
On Friday, June 03, 2016 05:54:53 pm Joseph Salowey wrote: > Unfortunately, the TLS record framing is not easily compatible with having > multiple keys used simultaneously: because we encrypt the content type, it > is not possible to use it to determine which key to use to decrypt. We > examined a number of proposals which would allow you to simultaneously have > encrypted content types and separate keys, but they all appear to be > nonviable for one reason or another: > >- Trial decryption has serious implementation problems >- Double-encrypting handshake messages in both the handshake key and the >application key does not actually provide the required key separation >- Separately encrypting the content type is inefficient in a number of >ways, especially for DTLS (and would need separate security analysis). This >is probably the most viable of the “try to get both” designs. Could someone please elaborate on why nested encryption would be a problem? No objection to avoiding trial decryption, though. The general expectation I would have for doing double encryption here would be to encrypt TLSCiphertext normally with the application traffic key and TLSCiphertext.content would be the real unencrypted length plus an aead-ciphered struct of the message which is encrypted with the relevant key. (the unencrypted length would be the inner encrypted block's length, in this scenario) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
The idea of using an empty extension as an indicator really isn't fundamentally different from what I'm suggesting here. We'd just have an arbitrary set of new version indicators mixed in with extensions instead of inside a new generalized basket. My replacement was (again, it's over a year old) designed to be a general purpose long-term solution that could handle 1.3, 1.4, draft versions, experiments, etc, without special-casing. I'm not fundamentally against just adding a TLS 1.3 version indicator extension and freezing the old version number to 1.2. It just feels a little more hacky to me, though in the short-term it's simpler. With respect to the concern of version numbers being moved to a non-fixed position, we could just require that the new version list extension be first or last in the extensions list. Being required to be last would also permanently mitigate the known issue of some buggy servers choking with an empty extension last. Conversely, with an empty extension indicator for each 1.3+ version, we'd probably want to require that to be first in the list to avoid that bug. (servers would of course still have to parse as an extension as not all clients will be sending 1.3+, so it's not reliably placed like the current hello version) Dave On Friday, June 03, 2016 02:19:52 pm David Benjamin wrote: > I think I could be convinced in either direction right now. > > It is definitely ugly and more of a nuisance to implement. The alternative > is a fallback and then painfully driving it out later. We've done that > before and we have FALLBACK_SCSV and the server_random trick now. > > At the same time, I am rather bored of this fallback game. We can actually > avoid the intolerance problem with this mechanism. Suppose we used empty > indicator extensions, one for each new version. Then as long as servers > tolerate unknown extensions, we'll be fine. So far this has not rusted yet, > and we can defend it from rust by having clients send random fake > extensions out of a range of values we burn for this purpose[*] (or private > use area). If one extension with a list of values, we can do something > similar. > > (Strictly speaking, the version already does not appear at a fixed position > because a ClientHello may be pathologically fragmented. OpenSSL even had > CVE-2014-3511 here. I believe the master branch no longer has a sniff-based > version negotiation. BoringSSL hasn't for a while now. But rejecting such > pathologically fragmented ClientHellos is reasonable and OpenSSL 1.0.x does > it now.) > > David > > [*] I'm planning on writing something up here soon. > > On Fri, Jun 3, 2016 at 1:40 PM Viktor Dukhovni > wrote: > > > On Fri, Jun 03, 2016 at 06:39:58AM -0700, Eric Rescorla wrote: > > > My opinion on this hasn't really changed since the last time. This seems > > > like it's more complicated and it's not clear to me why it won't lead to > > > exactly the same version intolerance problem in future. > > > > Doing version negotiation through extensions would be a major > > implementation burden. At present the client version appears early > > in the ClientHello at a fixed position in the packet, and the server > > can quickly grab the version, compute the highest shared version > > and branch to the protocol implementation for that version to parse > > the rest of the ClientHello. > > > > Putting the client version in an extension dramatically complicates > > server-side processing. So my view is that this would not be > > progress. This is IMNSHO even less likely to interoperate than > > what we have now. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
Allrighty then; time to dust off and rebase an old changeset I was fiddling with last year on this topic: https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9f1bd4096be9393f20076 (I cleaned up a bit when rebasing, but it probably needs some work; was just a WIP branch, never a PR) This was the result of prior discussions on-list about TLS version intolerance. The gist of the proposal: 1) Freeze all the various version number fields. 2) Send a list of all supported versions in an extension. (version IDs converted to 16-bit ints instead of 8-bit pairs) 3) Use short (1 or 2 value, based on hello version) predefined lists for hellos from old clients not sending the extension. 4) Compare lists to find highest overlap, avoiding guesswork or problems with noncontinuous lists. 5) Forget the old mess of version intolerance existed. Do we want to consider scrapping the old version negotiation method again? Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Issue 472: Remove redundant warning alerts
On Saturday, May 21, 2016 06:16:39 pm Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/472 > > http://tlswg.github.io/tls13-spec/#error-alerts says: > > Therefore, warning alerts are not very useful when > the sending party wants to continue the connection, and thus are sometimes > omitted. For example, if a party decides to accept an expired certificate > (perhaps after confirming this with the user) and wants to continue the > connection, it would not generally send a "certificate_expired" alert. > > It would probably be simpler to require that alerts either be warning or > fatal and that > the only warning alerts are the "Closure Alerts" specified in > http://tlswg.github.io/tls13-spec/#closure-alerts (or in some update > document) > rather than expect people to handle some warning version of the Error > Alerts. > > Thoughts? Does any implementation actually do anything with the warning version of alerts in question? If not, then this sounds like a reasonable simplification. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead
On Tuesday, April 26, 2016 11:20:40 am Hannes Tschofenig wrote: > If you are already paying the price of the asymmetric crypto (in terms > of flash usage/CPU speed/RAM utilization then just switch to a raw > public key or a certificate based ciphersuite (since there is very > little additional overhead). > > I suspect the usage is more for the we or so? (assuming that was supposed to be "web") With resumption now done through PSK in TLS 1.3, these suites will be desired for that in addition to systems that will be using PSK as their primary suite. Without them, the only FS AEAD PSK AES suites are DHE, and we'd much prefer ECDHE be available. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead
Just to make note on-list, I support adoption of the draft. I've already cited it in the current TLS 1.3 draft as a normative reference, and thus consider it required for completion of the new version. One objection to part of the current draft, though, which I think needs changing. It currently states that implementations have a MUST-level requirement to use no less than 255-bit curves with AES-128 and 384-bit curves with AES-256. Due to discussion on here a bit back, my current opinion is that the floor should be set to 255-bit for both. Yes, ideally you'd prefer comparable security levels, but AES-256 gives some PQ resistance and bigger ECC is just as dead there as with a smaller curve. Transitioning to stronger symmetric, over the long term, need not be held back by performance worries if some were required to use slower ECDHE, especially with some devices that may be using PSK for performance reasons. Also, I'd much prefer this be adopted as a separate draft and not merged fully into the TLS 1.3 draft. Dave On Monday, April 25, 2016 11:17:45 am Sean Turner wrote: > draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that are needed > for TLS1.3. We need to get these officially registered so the chairs would > like to hear whether there is WG support for adopting > draft-mattsson-tls-ecdhe-psk-aead. Please let us know whether you: > > - Support adoption and are willing to review/comment on the draft by > 201600429; the chairs still need people to review the draft to show there’s > support for it as we process it down the path. > > - Object to the adoption of this draft as a WG item, please respond to the > list indicating why by 201600429. > > Note 1: This draft will get published using the new rules we’ve been > concocting on the list so the IANA considerations section will get tweaked as > we settle on what words need to be included. > > Note 2: The other option is to put the registrations in the TLS1.3 spec, but > that would add four pages that I’m pretty sure no implementer is going to > read so there seems to be little point in included the registrations in the > TLS1.3 spec. And, these cipher suites do apply to TLS1.2. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0
On Friday, April 01, 2016 03:54:51 am Nikos Mavrogiannopoulos wrote: > On Wed, 2016-03-16 at 12:36 +, Peter Gutmann wrote: > > After a number of, uh, gentle reminders from people who have been > > waiting for > > this, I've finally got around to posting the TLS-LTS draft I > > mentioned a while > > back. It's now available as: > > > > > http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt > > I liked the idea of an LTS profile for TLS 1.2, however I just realized > that RFC7540 [0] blacklists (with no rationale) 3 out of the 4 LTS > ciphersuites and I'm wondering how practically useful will be that > profile. > > regards, > Nikos > > [0]. https://tools.ietf.org/html/rfc7540#appendix-A As no such TLS 1.2 LTS existed at the time of publication (which multiple people, including myself, said would have been better), some kind of sane cipher restrictions were needed to avoid perpetual use of obsolete crypto. The consensus was requiring TLS 1.2+ with only PFS+AEAD cipher suites, however at the last minute implementors started complaining about the requirements and it was reduced to a blacklist of non-compliant cipher suites instead of requiring them to just update their APIs to handle things properly. Noted at the end of the section: https://tools.ietf.org/html/rfc7540#page-94 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] AD review of draft-ietf-tls-falsestart-01
On Thursday, March 31, 2016 09:19:37 pm Sean Turner wrote: > (there’s probably some other options like an adding an IESG note/new section > that says “this goes to historic when TLS 1.3 is published, but I think the > above three options seem more realistic.) What looks simplest to me, would be to publish initially as experimental, then have the TLS 1.3 specification obsolete it and contain language that explicitly changes its status to historic without additional action. Consensus to change status would be considered a part of the required consensus to publish TLS 1.3 as an RFC. The current TLS 1.3 draft already handwaves an informational RFC to standards track (RFC5289: ECC AES GCM), so adding another handwave to change another RFC's status like this seems to make the most sense. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites
On Wednesday, March 30, 2016 03:20:08 pm Ilari Liusvaara wrote: > On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote: > > On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: > > > I am not sure that we want to be in the business of explicitly marking > > > things as insecure other than our own RFCs, though -- there could be an > > > implication of more review than is actually the case, which is what this > > > proposal is trying to get rid of. > > > > I think i agree with Ben here: if we have a tri-state: > > approved/not-approved/known-bad, then the people will infer that the > > not-approved ciphersuites are better than the known-bad ones, which > > isn't necessarily the case. > > > > I think i'd rather see it stay at "approved/not-approved" > > Then how should ciphersuites with explicit diediedie RFCs (currently > RC4) be presented? A tri-state that might be more acceptable would be approved/not-approved/amended, where "amended" indicates an RFC released after the initial specification that is considered mandatory. This would be both diediedie RFCs as well as any sort of less severe update, without as much implication that "not-approved" automatically implies safety. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?
On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote: > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to > PKIX. Adding a PKIX extension to mandate a minimum threshold of security configuration (e.g. PFS+AEAD w/o resumption or SHA1 or any support for TLS <1.2) would also be great to have. In fact, if an intermediate could also set such a requirement and have that be required for all end-entity certs signed by it, that'd be a great way to protect against downgrades. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A TLS extension transfering service indication information
On Tuesday, March 29, 2016 01:35:50 am Eric Mill wrote: > It looks like the abbreviation this draft uses is just "SI". It uses SNI at > the top a few times to refer to Server Name Indication (which it typos as > "service" name extension). > > On Tue, Mar 29, 2016 at 1:13 AM, Dave Garrett wrote: > > On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote: > > https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extension/ > > > > You really should not use SNI as your abbreviation, as it will just be > > frequently confused with the server_name extension which is already the > > dominant use of those initials in TLS. You're correct; my mistake. I didn't notice the typo and reading a spec draft whilst tired is not always the best of ideas. ;) CCing back to list and thread starter to make sure my correction is OTR for the list. Fixing that typo in the draft would help to avoid future misreadings. Sticking in a direct reference to RFC6066 on first mention of SNI could add another level of clarification, if desired. Thanks for quickly correcting me. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A TLS extension transfering service indication information
On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote: > https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extension/ You really should not use SNI as your abbreviation, as it will just be frequently confused with the server_name extension which is already the dominant use of those initials in TLS. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC
On Tuesday, March 22, 2016 08:38:13 pm Timothy Jackson wrote: > How would this group feel about a proposal to address this by specifying in > the 1.3 specification that implementations must ensure that the strength of > the certificate must be >= strength of ECDHE/DHE >= strength of the cipher? > Perhaps an equivalency rule for the MAC might also be in order? Apologies if > this is already resolved somewhere in the draft RFC. I looked but didn’t find > it. I've had a changeset sitting around for a while for recommendations (not hard requirements) to match the strengths for key exchange and bulk cipher key size. (it was leftover from a batch of other work, long since merged) That said, I'm not actually sure what my opinion is on this anymore. It's been on my todo list to bring up a discussion. https://github.com/tlswg/tls13-spec/pull/296 There's complications here that make picking a matching number less than straightforward: 1) A main reason to switch to 256-bit ciphers is for post-quantum crypto, but all (EC)DHE is completely broken in that scenario. Bigger numbers there won't help in any meaningful way. 2) Neither AES-256 nor ChaChaPoly match up things perfectly, already. For PRF, AES-256 uses SHA2-384, not SHA2-512; ChaChaPoly uses SHA2-256. AES-256 also has a 128-bit block size. 3) There's more to group security than bits. For a start: https://safecurves.cr.yp.to/ At this time, I'm leaning towards sticking in a recommendation to prioritize the following groups, in this descending order: X25519, secp256r1, X448, one of ffdhe3072 or ffdhe4096, and then lastly, ffdhe8192 and/or secp521r1 only as emergency backup (arguably, X448 belongs back here too) I'd like to specify ffdhe2048 (~103-bit strength) as "MUST NOT" use for TLS 1.3+ and only support it for transition in older TLS. (this came up on-list a long while ago, but needs further discussion) I'd state secp384r1 and ffdhe6144 as "NOT RECOMMENDED" to bother with, but still permitted (or, alternatively, just not explicitly recommended and not recommended against). I'd make the recommendation that X25519 and secp256r1, in that order, be sent in first-flight key shares, unless prior expectations exist for the server that another group is desired or required. Implementations would of course be permitted to send a more conservative set, such as (instead or additionally) X448 and ffdhe8192 or secp521r1, but even though I think this might make sense for 256-bit bulk ciphers, I concede that it would likely be overkill that wouldn't really help. Those who want something stronger should probably be refocusing their effort on getting some kind of PQ key exchange standardized. Am I somewhere in the ballpark of what the WG might deem appropriate here? There has been a "TODO" note sitting in the draft to address this for quite some time, and I'd like to get something in here at some point. Just to restate: my goal here is a set of recommendations to narrow down the zoo, not hard requirements (beyond requiring ~128+ bit strength security). Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
On Monday, March 21, 2016 09:59:27 pm Tony Arcieri wrote: > On Mon, Mar 21, 2016 at 12:42 PM, Dave Garrett wrote: > > Frankly, I think this document should be renamed "Extended Support > > Profile", rather than "Long-term Support Profile" (and ESP instead of LTS). > > Legacy Support Profile? Then you don't have to change the acronym I don't exactly see a 'T' for "LTS" in "Legacy Support Profile"... ;) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PSK in TLS 1.3
On Monday, March 21, 2016 06:08:45 pm Eric Rescorla wrote: > Ah, I see. Let me see if I can clear this up, if you wanted to send a PR, > that wouldn't help too. I assume you meant "wouldn't hurt" or "would help" here. ;) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
On Monday, March 21, 2016 10:38:43 am Hubert Kario wrote: > If your hardware really can't do anything better than 2048 bit RSA, it's > not LTS, it's a crippled embedded system, and it definitely shouldn't > get a stamp of approval "good for next X0 years" or anything similar > like a LTS moniker would imply. +1 Frankly, I think this document should be renamed "Extended Support Profile", rather than "Long-term Support Profile" (and ESP instead of LTS). In anything even approaching the long-term, TLS is dead due to the need for post-quantum crypto, yet to be defined. I'm not even convinced this document is capable of defining a known-good set that can survive for ten years, so that text should really be relaxed significantly. (in this context, 10 years is not "long-term") The bare minimum anyone should be stating for a 10 year window is something like 3248 bit RSA or ~256 bit ECDSA/EdDSA, and only with the qualifier that upgrades will probably be needed at some point over the next decade. Hardware that can't handle this is not short or medium-term viable, let alone long-term. https://www.keylength.com/en/3/ Hardware needs to accommodate the viable specifications, not the other way around. If it takes a second or two to perform a handshake, then that's what it takes until it's upgraded/replaced. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
https://tools.ietf.org/html/draft-gutmann-tls-lts-01#section-3.2 > TLS-LTS adds a hash of the domain parameters into the master secret > to protect against the use of manipulated curves/domain parameters: > > o TLS-LTS implementations MUST include a SHA-256 hash of the EDH or > ECDH parameters in the master secret computation by concatenating > the hash to the pre_master_secret value. In the case of EDH, the > value that's hashed is the ServerDHParams structure. In the case > of ECDH the value that's hashed is the ServerECDHParams structure. > This means that the master_secret computation becomes: > > master_secret = PRF(pre_master_secret || param_hash, "master secret", > ClientHello.random + ServerHello.random) > [0..47]; It would be a lot simpler, safer, and interoperable to just mandate use of the Extended Master Secret Extension [RFC 7627]. https://tools.ietf.org/html/rfc7627 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
On Wednesday, March 16, 2016 08:36:05 am Peter Gutmann wrote: > After a number of, uh, gentle reminders from people who have been waiting for > this, I've finally got around to posting the TLS-LTS draft I mentioned a while > back. It's now available as: > > http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt Allowing CBC+encrypt-then-MAC seems like a messy route when AEAD is already available and deployed more widely. If you want to permit it, please make it optional and only have AEAD ciphers as MTI. Also, you should add a recommendation/requirement of ChaChaPoly support in there so that there will be a backup in the long-term in the event of the need to panic disable AES under TLS 1.2 for some unforeseen reason. This is aiming to be an LTS, after all. The big glaring problem, however, in multiple places, are the statements that something is "implicit in TLS-LTS, there is no need to signal it" via its designated extension. No! These features MUST be implemented in full, according to their specifications, such that they will work fully with servers that support them but not this new LTS proposal. Skimping on this just makes this messy situation even messier, which is the opposite of what you're trying to do here. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data)
(This thread has gotten long and winding, so I'm replying to these two portions bellow under a new subject. Reply after quotations.) On Monday, March 14, 2016 02:38:27 pm Bill Cox wrote: > On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh wrote: > > On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox wrote: > >> As we all know, what matters most in security is the default mode. I am > >> suggesting making the default 0-RTT resumption mode stateful, with a > >> documented session-ID (and let's bring back the timestamp, too, since we'll > >> need it). > > > > Having state would make things much more robust; but rather than the state > > being around the channel itself (the TLS session), would it be more robust, > > and more flexible, for the state to be around the action? like some kind of > > hint cookie. > > It looks like server-side state is required to prevent replay. I don't > think any kind of token, cookie, or server-config can fix this. > > > One of the problems with session resumption is that in order to be replay > > safe; the sequence number has to restart where it left off. That requires > > some kind of transactional store, and if you're doing all of this for > > latency, you may end up eating all of the wins there. > > The new tickets can in theory end the debate over session caching vs > session tickets, since they can be used for database lookups or contain an > encrypted session state. However, the spec does not document how to do > session caching with tickets securely, which looks tricky. In reality, if > I were trying to build a speed and security sensitive site using TLS 1.3 > stateful 0-RTT resumption, I would probably do something like this: > > During the initial 1-RTT handshake: > - create a ticket containing only the session ID, resumption count, and a > session decryption key > - encrypt the session cache entry with the session encryption key stored in > the ticket > - encrypt the ticket with a semi-static ticket encryption key, which I > would rotate every few weeks > - send the ticket to the client, which is after encryption is enabled on > the connection > > During a 0-RTT resume handshake: > - check for a cache hit, and drop to 1-RTT if not found > - decrypt the ticket with ticket the semi-static ticket decryption key > - decrypt the cached session state with the session key from the ticket > - compare the resumption counts in the session state and ticket, and fall > back to 1-RTT if they do not match > - increment the resumption count > - create a new session ticket with a new session encryption key and the > updated resumption count > - encrypt the session cache entry with the new session encryption key > - send the client the new ticket On Monday, March 14, 2016 08:10:32 am Nikos Mavrogiannopoulos wrote: > It is important to see how protocols are perceived. For many people TLS > 1.3 with 0rtt will be the same as TLS 1.3. The first publication of an > attack against TLS 1.3 with rtt, will be perceived as an attack against > TLS 1.3 protocol. Even if the published attack against TLS 1.3 with > 0rtt was an expected one (i.e., replay of data), if the attack impact > is high, that may not be sufficient to stop the avalanche of bad > publicity. In turn that will lead several people losing confidence to > TLS 1.3 as a protocol, even TLS and the IETF process overall. > > My suggestion, if you need 0rtt, publish it as a different document, > don't mix it with TLS 1.3. The security requirements from TLS are > vastly different from the security requirements of a 0rtt protocol. Previous discussion seemed to land on the conclusion that semi-static DH 0RTT should be defined in a separate document, and after this discussion I'm beginning to agree that all stateless 0RTT should be defined as a separate companion document to the main TLS 1.3 specification. We can likely agree on defining a stateful 0RTT PSK resumption system which is sufficiently safe and mistake-resistant, and we could restrict the official TLS 1.3 spec to only specify that, whilst referencing the other document as a more experimental feature that could be available to certain applications (possibly a non-standards-track document). HTTPS could then, itself, have a separate document laying out the necessary practices to do stateless 0RTT safely, and other applications should be warned that without a similar such document, things are very risky. Is this in the ballpark of what the WG could agree on to help mitigate some of the problems here? Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04
On Thursday, March 10, 2016 02:41:58 pm Stephen Farrell wrote: > My question is: Should the WG take the opportunity to more > tightly define the key exchange parameters for these > ciphersuites? > > For example, TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 could > REQUIRE RSA keys with >=2048 bit moduli and one could go > further and say that this also REQUIRES use of specific > integer DH groups. Etc etc. This is a good idea that I think is likely to be impractical and could greatly hurt adoption, at least with regard to RSA. Requiring only secure (EC)DHE groups, however, I think is probably worth consideration. Both could be dealt with in a single TLS stack update, but requiring better certs is still a pain for entirely too many (hopefully this won't be true for that much longer). Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Accepting that other SNI name types will never work.
Do we want to stick some simple new constraints on SNI in the TLS 1.3 draft spec? e.g. SHOULD have exactly one host_name which SHOULD be less than N bytes (significantly less than the current theoretical 64kB ceiling). Just adding a quick blurb for this in there somewhere seems like the simplest solution to me. Dave On Thursday, March 03, 2016 06:16:25 pm Martin Thomson wrote: > If we actually have a volunteer for sni-bis, then that would be OK with me. > > However, I don't regard the errors as important. Any hope that they > might be used in some automated fashion died a long time ago. Mainly > due to this complete lack of consistency. I assume that the last > error indicates that you didn't get an alert, which I find is > alarmingly common in TLS. > > On 4 March 2016 at 09:52, Richard Moore wrote: > > If you're fixing that then maybe standardising the errors makes sense too. > > My fingerprinter sees the following: > > > > For an empty name: > > > > SNIEmptyName: *(301)alert:DecodeError:fatal| > > SNIEmptyName: *(301)alert:HandshakeFailure:fatal| > > SNIEmptyName: *(301)alert:IllegalParameter:fatal| > > SNIEmptyName: *(303)alert:UnexpectedMesage:fatal| > > SNIEmptyName: error:Unexpected EOF receiving record header - server closed > > connection| > > > > For a long name (x repeated 500 times): > > > > SNILongName: *(301)alert:HandshakeFailure:fatal| > > SNILongName: *(301)alert:IllegalParameter:fatal| > > SNILongName: *(301)alert:UnrecognizedName:fatal| > > SNILongName: *(303)alert:UnexpectedMesage:fatal| > > SNILongName: error:Unexpected EOF receiving record header - server closed > > connection| > > > > Rich. > > > > > > On 3 March 2016 at 22:44, Martin Thomson wrote: > >> > >> On 4 March 2016 at 05:49, Adam Langley wrote: > >> > (I think the lesson here is that protocols should have a single joint, > >> > and that it should be kept well oiled. For TLS, that means that > >> > extensions should have minimal extensionality in themselves and that > >> > we should generally rely on the main extensions mechanism for these > >> > sorts of things.) > >> > >> Big +1 > >> > >> Note that the NSS bug also entailed non-zero SNI name types > >> overwriting the actual SNI. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On Wednesday, March 02, 2016 01:57:48 am Viktor Dukhovni wrote: > adaptive attacks are I think a greater potential > threat against interactive TLS than against a bunch of CA-authored > bits at rest. +1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On Monday, February 29, 2016 03:35:57 pm Andrey Jivsov wrote: > I think that supporting PKCS1.5 fallback is the right thing to do for > wider adoption of TLS 1.3, as specified above. I think it's long past the time where everyone has to acknowledge that within protocols, there's no such thing as a "fallback" specified as an option. There's simply allowed and not allowed, with the former having no incentive to go away. Arguing to keep it now is equivalent to arguing to keep it forever. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Remove DH-based 0-RTT
On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote: > I propose that we remove DH-based 0-RTT from TLS 1.3. > > As ekr's previous mail noted, the security properties of PSK-based > 0-RTT and DH-based 0-RTT are almost identical. And DH-based 0-RTT is > much more complex. > > For those who love DH-based 0-RTT, and I know that some people are > fans, here's something that might make you less sad about removing it > from the core spec. You can use DH out of band to negotiate a PSK. > You might even do this as an extension to TLS, but that's of less > value. I think there is a good argument for moving DH 0RTT into a TLS extension. Implementations that are explicitly not going to use it should not be expected to implement it and risk screwing it up. If we accept that premise that online DH 0RTT will be unlikely in practice, then we would be specifying it at least primarily for out-of-band use, and doing it via an extension will probably be cleaner and safer. I would still prefer it be defined in the TLS 1.3 specification document, though optional. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?)
On Friday, February 19, 2016 07:47:31 pm Martin Thomson wrote: > This really only helps on the first connection attempt. Browsers > already pre-warm connections to subresource hosts. The first connect is important, as are new connections after a cache clear (think also, private browsing modes). Providing this capability to TLS 1.3 clients (likely also requiring HTTP/2) would allow for browsers to explicitly have a way to do this, rather than speculatively "pre-warm" connections. Additionally, servers could push a cached config for links on pages if they wanted to. Servers supporting this could effectively chain together to give 0RTT for virtually all normal user connections. Clients would not have to open connections to arbitrary link destinations in order to optimize away this 1RTT. (yes, there's the TCP 1RTT too, but that's a separate issue) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?)
I just had an idea. There is significant doubt of how useful semi-static DHE 0RTT would be due to the difficulty of distributing the configs out-of-bound. I don't dispute this; I merely dispute that no capability is better than minimal, in this realm. There is another way that they could be helpful, however. Take a typical HTTP page and a client with no prior knowledge. (could be applicable to other applications, but the TLS WG does have a charter to take special note of HTTP latency; subresources' lack of HTTPS often is a stated reason for a site's lack of HTTPS overall) There will be a 1RTT cost without having a pre-cached way to do 0RTT, and then after that there will be a 1RTT cost for *every* subresource on a different server. To do HTTPS for the servers of 3rd party scripts, ads, user-posted images/video embeds, etc., each of those servers will need to be connected to by the client with TLS and no prior knowledge, meaning a 1RTT cost. This could be significantly optimized by creating a new HTTP extension that allows servers to enumerate the domains on a page, cache all those domains' semi-static DHE config, and push them to each client in their first flight returning the primary resource. This would allow all subresources to be fetched by the client with a 0RTT cost, and just a sin gle 1RTT cost for the primary resource. Servers could simply refresh their cache of their subresources' semi-static DHE configs on a daily basis. A stale config can be sent to a client and it can still fallback to 1RTT, though. Clients would not need to have any prior knowledge in order to significantly benefit from 0RTT in this scenario. TLS 1.3 would need to have some way of facilitating this scenario in order to devise a way to do this sort of thing in HTTP (or another general protocol with subresources). The general point I'm trying to convey here is that we can come up with ways to use this to improve latency noticeably, if given the underlying capability. We don't know how effectively it can be used until we try. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?
On Friday, February 19, 2016 05:24:25 pm Eric Rescorla wrote: > My impression is exactly the opposite. All the infrastructure to > PSK-resumption and > hence PSK-0RTT is already in place for TLS 1.2. And of course PSK-resumption > is also much faster. That's good to hear. The perf advantage is why I'm not advocating dropping it; merely saying that I too would prefer a single method if it didn't loose capability. Dropping PSK resumption drops less than dropping DHE 0RTT, but keeping both seems like the best option at the moment. > On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett wrote: > > It would mean that TLS only has 0RTT resumption and not actually have any > > 0RTT sessions. > > Why do you think that this makes a material difference? One of the fundamental complaints about TLS, performance-wise, is the added round trip time over plaintext. That's why the WG made a point to focus on adding 0RTT in the first place. Someone considering upgrading from HTTP to HTTPS generally has this concern (or any other protocol to a variant over TLS). With only PSK resumption, we can still always have a 1RTT hit on first connection, and revert to that after the session is considered expired. With DHE 0RTT we have a longer term config that could allow for more generic caching and distribution and thus not have to get that 1RTT hit in many scenarios. The lack of a current ability to easily distribute a new config system should not be used as evidence against creating a new config system that we would want to create a way to easily distribute. Even dumping the top few dozen sites' 0RTT DHE config into a static file in a client update would be a noticeable improvement over not doing so. Coming up with a better method can come next. People should be using TLS or encryption in general as a matter of responsibility, but they don't. Softening *all* barriers to them upgrading is very necessary to get more to switch. 0RTT PSK only gets rid of a delay in continuing a session, which in some use-cases might be minimally noticeable. 0RTT DHE allows for a first-connect with comparable speed to plaintext (in scenarios where 0RTT data is safe, namely most HTTP). Within the context of HTTP, which is singled out as a focus in the TLS WG charter, 0RTT DHE will provide a more noticeable latency reduction in comparison to 0RTT PSK only. Another issue is that of privacy with session resumption. If the only way to get 0RTT is to keep sessions alive, then clearing that cache on the client side costs a future 1RTT. You can, however, cache 0RTT DHE configs safely for a longer time because they are not specific to the user agent. (we should probably narrow the spec to state that configs SHOULD NOT be per-client) In order to reliably get 0RTT without DHE configs, applications/services would need to cache PSK resumption sessions for as long as possible, which leaves a distinct per-user marker on both the client and server. Anyone trying to optimize away the 1RTT hit of first-connect will be required to maintain a system that keeps more user identifiable information than we should want. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?
On Friday, February 19, 2016 12:57:04 am Bill Cox wrote: > Having two different modes to achieve basically the same > thing in TLS 1.3 is a bad idea. On Friday, February 19, 2016 10:01:31 am Salz, Rich wrote: > I greatly prefer one way to do things. I do not fundamentally disagree. I would support dropping PSK resumption in favor of using only DHE 0RTT for resumption. With PSK resumption, as far as I know, the issue of what cipher suites to offer & use has not been settled, or at least written down in the spec. Not having to use all of the PSK suites (or non-PSK suites but actually using PSK, which could be confusing) and the PSK extension for resumption, and instead using some session ID and DHE 0RTT would be simpler and not loose capability. I think that requiring PSK for 0RTT would significantly reduce the availability of actually using 0RTT, whilst providing no way to improve the situation over the long term. It would mean that TLS only has 0RTT resumption and not actually have any 0RTT sessions. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?
On Thursday, February 18, 2016 08:04:05 pm Eric Rescorla wrote: > PUBLISHED CONFIGURATIONS > The semi-static mode in principle allows the server to publish its > configuration (i.e., it's semi-static key), e.g., via DNS, which the > client can then use for 0-RTT handshakes on first contact. However, > recent conversations (especially with the guys from Cloudflare) have > convinced me that this probably isn't useful: DNS TXT record > penetration rates are really bad and all the other proposed mechanisms > are also pretty problematic. For the few protocols where I was > thinking that this sort of priming was attractive, it turns out not to > work well or to have other easier workarounds. > > WHAT ARE THE OPTIONS > 1. Simply leave things as-is. Nobody has enough of a reason to have support for DNS records that can do this, yet. Adding it here could change the situation over time. More importantly, some major sites/services might even want to just cut out the middle-ware and dump 0RTT configs into a client synced list of some sort, akin to how some handle HPKP. Not the most elegant of systems, but it would let clients that use such a list have out-of-the-box 0RTT to major high-traffic sites. Ad hoc systems would also be able to preload for 0RTT for their services easily (e.g. make an app & include 0RTT config cache with it). Even for clients merely getting their config via a first connection, we might be more likely to be able to cache for DHE safely longer than just for PSK for every client. I think it's a feature worth keeping. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05
Permanently gobbling up the majority of the codespace feels like excessive force here. For TLS 1.3, the first byte will always be one of alert(21), handshake(22), or application_data(23), even for custom types. The stated type for TLSCiphertext has been frozen to application_data(23) with the actual type for the payload now in the encrypted fragment. (this is of course assuming we don't eventually drop the frozen type & version here, which now sounds unlikely if we're having to deal with design flaws like this) Even handshake records after the hellos will have an opaque_type of application_data(23), with the encrypted fragment.type containing the actual handshake(22) designation. All TLS 1.3+ packets will be detected with the RFC 5764 Section 5.1.2 algorithm even if new types are allocated in the proposed reserved ranges. Locking down the <1.2 registry seems fine, however 1.3+ should be able to do whatever it needs as its encrypted type is not going to get accidentally read & misinterpreted by anything. https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-5.2.2 https://tools.ietf.org/html/rfc5764#section-5.1.2 https://tools.ietf.org/html/draft-ietf-avtcore-rfc5764-mux-fixes-05#section-4 Dave On Monday, February 08, 2016 12:21:02 am Joseph Salowey wrote: > This document is relevant to the TLS working because it reserves a large > portion of the TLS content type space. The values 0-19 and 64-255 cannot > be used without checking for conflicts with SRTP-DTLS's wacky > demultiplexing scheme. In TLS 1.3 we will move more encrypted content > types which should limit the impact this unfortunate design on TLS > evolution, but the working group should be aware of this. > > > On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund > wrote: > > > AVTCORE and TLS, > > > > TLS WG, you are included in this WG last call, as this document affects > > the TLS ContentType IANA registry. > > > > This email starts a two week WG last call, that ends on the 10th of > > February. The intended status of this document is standards track (Proposed > > Standard). > > > > The document can be retrieved here: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Require deterministic ECDSA
On Saturday, January 23, 2016 07:47:11 pm Michael StJohns wrote: > 1) A receiver of an deterministic ECDSA signature verifies it EXACTLY > like they would a non-deterministic signature. > 2) A receiver of an ECDSA signature cannot determine whether or not the > signer did a deterministic signature. > 3) A TLS implementation has no way (absent repeating signatures over > identical data) of telling whether or not a given signature using the > client or server private key is deterministic. > > All that suggests that this is a completely unenforceable requirement > with respect to TLS. We can have unverifiable & unenforceable MUSTs. A SHOULD might be more appropriate, however, if we want to acknowledge this limitation to some degree. > The above is a long way of saying that this is a WG overreach on > internal security module behavior that is not central, cognizable or > identifiable to a TLS implementation. As far as I'm concerned, anything that directly affects the security of TLS is not an overreach. Beyond scope of control, yes, but it's not an overreach to lay out how to do things properly that commonly result in vulnerabilities with TLS. Like everything else in an RFC, it can of course be ignored, but I think it's worth it to make an official statement in the spec on how to do things properly. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS > 1.2, signature algorithms are spread across the handshake. [...] > I propose we fold the negotiable parameters under one name. [...] > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm as > they are. Introduce a new SignatureAlgorithm u16 type and negotiate that > instead. I previously proposed this here: https://www.ietf.org/mail-archive/web/tls/current/msg18035.html ekr was against it, though it hasn't been discussed that throughly. https://www.ietf.org/mail-archive/web/tls/current/msg18036.html Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
