Re: [TLS] No cypher overlap
* Hubert Kario: > On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote: >> In that case, it should be said that a client MUST NOT advertise >> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers >> (or perhaps less restrictive at least one TLS 1.3 compatible cipher). > > MTI does not mean Mandatory To Enable Are you sure? That's extremely surprising. Of course, people are free to run the servers in odd configuration, but my understanding is that's not TLS anymore. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] No cypher overlap
* Viktor Dukhovni: > In that case, it should be said that a client MUST NOT advertise > TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers > (or perhaps less restrictive at least one TLS 1.3 compatible cipher). Or the server should negotiate TLS 1.2 instead. Servers should already do something similar today: For an extension-less TLS 1.2 handshake, they should negotiate TLS 1.1 instead, to get a stronger PRF. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus on PR 169 - relax certificate list requirements
On 08/26/2015 11:42 PM, Dave Garrett wrote: > On Wednesday, August 26, 2015 05:11:01 pm Joseph Salowey wrote: >> It looks like we have good consensus on PR 169 to relax certificate list >> ordering requirements. I had one question on the revised text. I'm >> unclear on the final clause in this section: >> >> "Because certificate validation requires that trust anchors be distributed >> independently, a self-signed certificate that specifies a trust anchor MAY >> be omitted from the chain, provided that supported peers are known to >> possess any omitted certificates they may require." >> >> I just want to make sure there isn't the intention of omitting certificates >> that are not seif-signed. > > Well, technically anything can be omitted; it just won't validate. :p Firefox completes chains with intermediate certificates it has seen in other certificate chains. This is an endless source of headaches if you use headless clients which do not perform this caching. In this light, MUST NOT automatically complete incomplete chains, except with a trusted root certificate (self-signed or not) might an attractive option. Except that Mozilla could claim its self-learning trust store is just magically growing root certificates in the sense of such a requirement (although such certificates are necessarily intermediate, otherwise it would not be safe to mark them as trusted automatically). -- Florian Weimer / Red Hat Product Security ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus on PR 169 - relax certificate list requirements
On 08/31/2015 05:54 PM, Martin Thomson wrote: > On 31 August 2015 at 05:02, Florian Weimer wrote: >> MUST NOT automatically complete incomplete chains > > Um, no. I realize that this is a feature that is hard for others to > replicate, but being able to reach sites is important to people. All > browsers do this, and I don't see any reason to stop. The reason to stop is that people only test with long-running, well-used browser profiles, and it is difficult to explain to them that things don't work if you just installed a fresh system. I lost countless hours to that. As in other cases, browsers papering over site configuration errors causes ecosystem damage. -- Florian Weimer / Red Hat Product Security ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On 09/12/2015 10:49 PM, Eric Rescorla wrote: > Issue: https://github.com/tlswg/tls13-spec/issues/242 > > In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues: > > "Nobody must ever be *required* to send an alert. Any requirement for > sending an alert should be SHOULD, at most." Using full-duplex TCP, it's difficult to get a fatal alert over the wire if you want to close the connection immediately: <http://www.ietf.org/mail-archive/web/tls/current/msg08342.html> The workarounds proposed in that thread may not be always practical. -- Florian Weimer / Red Hat Product Security ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On 09/15/2015 06:29 PM, Nico Williams wrote: > On Tue, Sep 15, 2015 at 03:18:30PM +0200, Florian Weimer wrote: >> On 09/12/2015 10:49 PM, Eric Rescorla wrote: >>> Issue: https://github.com/tlswg/tls13-spec/issues/242 >>> >>> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues: >>> >>> "Nobody must ever be *required* to send an alert. Any requirement for >>> sending an alert should be SHOULD, at most." >> >> Using full-duplex TCP, it's difficult to get a fatal alert over the wire >> if you want to close the connection immediately: > > But if you have a fatal error you'll be closing immediately anyways. > Does sending the fatal alert cause a problem other than increase the > likelihood of RSTs? What is the alternative considering that the next > step is to close the connection anyways? I'm trying to explain that any requirement to send fatal alerts will be difficult to implement. With the BSD sockets API, the only way to do that reliable is *not* to close the socket immediately, which is apparently not what you (or existing APIs) expect, and which is where the difficulty lies. -- Florian Weimer / Red Hat Product Security ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On 09/16/2015 01:51 PM, Henrik Grubbström wrote: > On Wed, Sep 16, 2015 at 12:02 PM, Florian Weimer wrote: >> On 09/15/2015 06:29 PM, Nico Williams wrote: > [...] >>> >>> But if you have a fatal error you'll be closing immediately anyways. >>> Does sending the fatal alert cause a problem other than increase the >>> likelihood of RSTs? What is the alternative considering that the next >>> step is to close the connection anyways? >> >> I'm trying to explain that any requirement to send fatal alerts will be >> difficult to implement. With the BSD sockets API, the only way to do >> that reliable is *not* to close the socket immediately, which is >> apparently not what you (or existing APIs) expect, and which is where >> the difficulty lies. > > What about SO_LINGER? With full-duplex connections, it does not make a difference. TCP will still detect a data loss event, send the RST segment, and discard the queued fatal alert. -- Florian Weimer / Red Hat Product Security ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On 09/16/2015 09:53 PM, Brian Smith wrote: > Assume the client and the server implement the mandatory-to-implement > parameters and that both the client and the server are otherwise > conformant. In this scenerio, when would an alert other than the non-fatal > close_notify be sent? I have been told that mandatory-to-implement does not mean mandatory-to-enable, and that it is possible to run a nominally RFC-conforming client or server in a mode which is not interoperable with anything else. Under such a scenario, fatal alerts happen without an attack. Most fatal alerts in the wild appear to be harmless in the sense that they are not due to attacks, but due to interoperability failures (due to not enabling mandatory-to-implement cipher suites, self-signed certificates, incomplete certificate chains, or just bugs). -- Florian Weimer / Red Hat Product Security ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On 12/21/2015 01:41 PM, Hubert Kario wrote: > if the rekey doesn't allow the application to change authentication > tokens (as it now stands), then rekey is much more secure than > renegotiation was in TLS <= 1.2 You still have the added complexity that during rekey, you need to temporarily switch from mere sending or receiving to at least half-duplex interaction. Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On 12/28/2015 09:11 PM, Eric Rescorla wrote: >> You still have the added complexity that during rekey, you need to >> temporarily switch from mere sending or receiving to at least >> half-duplex interaction. >> > > That's not intended. Indeed, you need to be able to handle the old key > in order to send/receive the KeyUpdate. Can you elaborate on your concern? Ah, so you want to keep the current mechanism and not inject fresh randomness? Isn't this fairly risky? Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On 01/04/2016 12:59 PM, Hubert Kario wrote: > On Monday 28 December 2015 21:08:10 Florian Weimer wrote: >> On 12/21/2015 01:41 PM, Hubert Kario wrote: >>> if the rekey doesn't allow the application to change authentication >>> tokens (as it now stands), then rekey is much more secure than >>> renegotiation was in TLS <= 1.2 >> >> You still have the added complexity that during rekey, you need to >> temporarily switch from mere sending or receiving to at least >> half-duplex interaction. > > this situation already happens in initial handshake so the > implementation needs to support that But after and the handshake and without real re-key, sending and receiving operations exactly match what the application requests. If you need to switch directions against the application's wishes, you end up with an API like OpenJDK's SSLEngine (or a callback variant which is equivalent in complexity). Dealing with this during the initial handshake is fine. But supporting direction-switching after that is *really* difficult. Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On 12/28/2015 10:09 PM, Salz, Rich wrote: >> When the key is changed, the change procedure should involve new randomness. > > I don't think this is necessary, and I don't think the common crypto > expertise agrees with you, either. But I am not a cryptographer, maybe one of > the ones on this list can chime in. > > "Crank the KDF" suffices. The attacks against GCM are at the stage where even “periodically increment the key by one“ would thwart them, right? The risk is that without real re-key (introducing additional randomness), someone might come up with a better attack that reduces the security level below the design target, and which requires similar effort as the existing GCM attack (four years of traffic at terabit speed, it seems). Real re-key is difficult to introduce as an afterthought (see my recent response to Hubert), and I'd rather see such issues fixed at the cipher level if at all possible. The current update-key mechanism doesn't have the complexity issue of real re-key, but it's ambiguous if it's a design goal to paper over cipher deficiencies in the rest of the protocol. Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On 01/04/2016 01:19 PM, Hubert Kario wrote: >> Dealing with this during the initial handshake is fine. But >> supporting direction-switching after that is *really* difficult. > > yes, this is a bit more problematic, especially for one-sided transfers. > For example, when one side is just sending a multi-gigabyte transfer as > a reply to a single command - there may be megabytes transferred before > the other side reads our request for rekey and then our "CCS" message Yes, this is the issue I meant. I simply don't see a way to re-inject new randomness without a round-trip. (Key update without new randomness doesn't face this challenge, but then it's mostly cheating.) Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Errata Rejected] RFC6176 (5520)
* RFC Errata System: > Corrected Text > -- >o The root certificate authority keys are overexposed. The server > sends only one certificate signed by a root certificate authority, > which means a frequent use of this authority keys for signing new > certificates. This use can lead to key loss and the compromise of > all certificates previously signed including the root certificate. > > Notes > - > Adding a deficiency. > Recent history showed that well-known authorities could loose their keys and > it had a wide impact on security. > SSL 2.0 limits the certificate handshake message to one single certificate, > thus making it impossible to send a certificate chain. > A certificate chain doesn't completely prevent key loss, but it gives more > protection to the root certificate keys which can be stored and hidden until > we need them again, which is much less often than without chaining. > > > > --VERIFIER NOTES-- >This isn't an error in the original document. It's new text you want to > add. I think it's also historically incorrect. More security problems were caused by the ability to introduce arbitrary intermediate certificates by CAs than by too many direct signing operations with a root CA key. At least for web use, the original model (which does not allow delegation of trust on the CA side) might actually have been more approriate. (On the RA side, delegation is of course technically possible under any model, and it had its share of problems, too.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNIKeys over complex
* Paul Wouters: > On Wed, 21 Nov 2018, Stephen Farrell wrote: > >>> We currently permit >1 RR, but >>> actually >>> I suspect that it would be better to try to restrict this. >> >> Not sure we can and I suspect that'd raise DNS-folks' hackles, >> but maybe I'm wrong. > > I think the SOA record is the only exception allowed (and there > is an exception to that when doing AXFR I believe) > > Usually these things are defined as "pick the first DNS RRTYPE > that satisfies you". Not sure what you mean by that (RRTYPE?). The DNAME algorithm (RFC 6672) only works if there is a single DNAME record for an owner name. RFC 1034 is also pretty clear that only CNAME record is permitted per owner name. To be honest, I don't expect much opposition from DNS people, as long as there is no expectation that the DNS layer is expected to reject multiple records. If the higher-level protocol treats non-singleton RRsets as a hard error, I expect that would be fine. DNS treats RRsets as an atomic unit, so there is no risk here that a zone file change ends up producing a multi-record RRset due to caching. Thanks, Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Delegated Credentials and Lawful Intercept
Would it be possible to use delegated credentials to address lawful intercept concerns, similar to eTLS? Basically, the server operator would issue a delegated credential to someone who has to decrypt or modify the traffic after intercepting it, without having to disclose that backdoor in certificate transparency logs. And in a data center scenario, perhaps people feel more comfortable loading those short-term credentials into their monitoring equipment. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] debugging tools [was: Industry Concerns about TLS 1.3]
* Hubert Kario: > those secret keys are on the client machines and they will stay on client > machines > > making it hard to extract master key from process memory is just security > through obscurity, not something that will stop a determined attacker I think extracting the master key is probably not what you want to do anyway, just adding Systemtap probes to get cleartext copies (preferably along with connection detail information) should be sufficient. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Industry Concerns about TLS 1.3
* BITS Security: > Deprecation of the RSA key exchange in TLS 1.3 will cause significant > problems for financial institutions, almost all of whom are running > TLS internally and have significant, security-critical investments in > out-of-band TLS decryption. > > Like many enterprises, financial institutions depend upon the ability > to decrypt TLS traffic to implement data loss protection, intrusion > detection and prevention, malware detection, packet capture and > analysis, and DDoS mitigation. We should have already seen this with changing defaults in crypto libraries as part of security updates. That should have broken passive monitoring infrastructure, too. Maybe some of the vendors can shed some light on this problem and tell us if they ever have received pushback for rolling out ECDHE-by-default. (I know that some products have few capabilities for centralized policy management, which is why defaults matter a lot there.) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
On 10/13/2017 02:45 PM, Stephen Farrell wrote: So the problems with that are numerous but include: - there can be >1 carol, (and maybe all the carols also need to "approve" of one another), if we were crazy enough to try do this we'd have at least: - corporate outbound snooper - data-centre snooper (if you buy those supposed use-cases) - government snooper(s) in places where they don't care about doing that openly ...port 80 would suddenly be quicker than 443 again;-( And any authorized eavesdropper is not allowed to be able to infer if they are the only ones listening in. I don't understand why this complicated approach is needed. Why can't the server provide an OOB interface to look up sessions keys, or maybe export them proactively? The proposed draft needs a protocol like this anyway because SSWrapDH1 keys need to be distributed, and periodic key regeneration is needed because it is the only way to implement revocation of access privileges without revealing the existence of other authorized parties. I don't buy the argument that there are too many session keys for proactive export. Obviously, you already have sufficient capacity to send these keys (or an equivalent) over the wire once, so sending another copy or two shouldn't be a problem. Thanks, Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] network-based security solution use cases
* Nancy Cam-Winget: > @IETF99, awareness was raised to some of the security WGs (thanks > Kathleen ☺) that TLS 1.3 will obscure visibility currently afforded in > TLS 1.2 and asked what the implications would be for the security > solutions today. > https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is an > initial draft to describe some of the impacts relating to current > network security solutions. The goal of the draft is NOT to propose > any solution as a few have been proposed, but rather to raise > awareness to how current network-based security solutions work today > and their impact on them based on the current TLS 1.3 specification. I'm not sure if this approach is useful, I'm afraid. The draft is basically a collection of man-in-the-middle attacks many people would consider benign. It's unclear where the line is drawn: traffic optimization/compression and ad suppression/replacement aren't mentioned, for example, and I would expect both to be rather low on the scale of offensiveness. What the draft is essentially arguing is that many user cannot afford end-to-end encryption for various reasons, some legal, some technical, some political. But it seems to me that this is currently not a viewpoint shared by the IETF. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
