Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Hi Ben, Am 16.09.20 um 08:31 schrieb Achim Kraus: Hi Ben, If I did't get it, it may be easier to discus this as issue in the github repo. I think you got it; I am just failing to remember where the "MUST anyway use new handshakes" requirement comes in from. And I guess that also raises the question of what the expected behavior is when a server expects CID-ful traffic on a given 5-tuple and receives an (unencrypted) ClientHello on that 5-tuple. "when a server expects CID-ful traffic on a given 5-tuple" I'm not sure, why that should happen. If CID is used, the server should not expect a given 5-tuple (at least not longer than a few seconds). If a new CLIENT_HELLO arrives, it's first challenge it with a HELLO_VERIFY_REQUEST. If that verification succeeds and a "old 5-tuple of a previous CID message" is hit, then just mark/remove the 5-tuple of that CID association. That mainly means, you will not be able to reach the CID peer with that 5-tuple. That's anyway extremely common to lose the ip-route to such CID peers, otherwise CID would not be required. Let me add: - If the scenario uses "dynamic 5-tuples, with CID or without" and "static 5-tuples without CID", - then an attack, with the spoofed 5-tuple (out of that static-5-tuple" pool) and CID (described in https://github.com/tlswg/dtls-conn-id/issues/64), may disrupt the communication to such a static-5-tuple without CID. Even then, that "static-5-tuple" peers must be anyway aware, that sometimes new handshakes are required. So that scenario may also depend more on the volume of such attacks, than just on the pure possibility. In my experience, such "static-5-tuples" are rare and I would guess, they will benefit from different handling also for other reasons. Therefore I would just spend them an separate endpoint to separate their traffic. best regards Achim ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets
Sounds good to me. I'm happy to send a PR making these changes, but couldn't find the repository for the document. Could you please point me to it? best, Nimrod On Thu, 17 Sep 2020 at 17:12, Douglas Stebila wrote: > Given that all the finalists and alternate candidates have fixed > length shared secrets, and your observations on the potential for > timing attacks, I'm fine with dealing with only fixed length secrets, > removing the paragraph discussing the possibility for variable-length > shared secrets from the TLS 1.3 hybrid KEX draft, and adding a note > regarding the risks as identified by the Raccoon attack. > > Douglas > > > On Wed, Sep 16, 2020 at 12:27 PM Nimrod Aviram > wrote: > > > > Dear all, > > > > We are writing to ask about the possible security impact of > > variable-length secrets on the "Hybrid key exchange in TLS 1.3" RFC > > [1]. > > > > As you probably know, when using key material of variable length > > and processing this material using hash functions, a timing side > > channel may arise. In broad terms, when the secret is longer, the hash > > function may need to process more blocks internally. In some unfortunate > > circumstances, this has led to timing attacks, e.g. Lucky Thirteen [2] > > and the newly-disclosed Raccoon Attack [3]. To be clear, we are not > > aware of any attack on the proposed standard. Rather, we view this as > > an opportunity to defend-in-depth against such attacks, while work on > > the standard is in progress. > > > > Our proposal is to add language to the RFC explaining that > variable-length > > secrets may enable such attacks, and should therefore be avoided when > > possible. Currently, the language seems to allow for variable-length > > secrets, should the need arise: > > "Variable-length shared secrets ... if it is envisioned that this > specification > > be used with algorithms which do not have fixed-length shared secrets > ..." > > > > We also note that a related RFC exists, "Hybrid Post-Quantum Key > > Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2" > > [4]. However, that RFC apparently only uses BIKE, Kyber or SIKE as the > > PQ KEM. To our knowledge, all three KEMs have fixed-length secrets. It > > may be prudent to add cautionary language to that document as well, > > in case other KEMs are used in the future. > > > > Kind regards, > > The Raccoon Team > > > > [1] > https://www.ietf.org/id/draft-ietf-tls-hybrid-design-00.html#name-open-questions > > [2] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6547131 > > [3] https://raccoon-attack.com/ > > [4] > https://tools.ietf.org/id/draft-campagna-tls-bike-sike-hybrid-05.html#name-key-exchange-algorithms > > > > > > ___ > > 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] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate
Rich, Just to close the loop on this, there are three values: Y, N, and blank. I tend to think we should mark is as “N”: If an item is not marked as "Recommended" (i.e., "N"), it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. That specific use case is two servers talking an old version to each other in whatever setting they are being used in. Also, should we be adding “_legacy” to the names of the code points as was done for rsa_pkcs1_sha256_legacy by: https://www.ietf.org/archive/id/draft-davidben-tls13-pkcs1-00.txt? spt > On Jun 25, 2020, at 08:35, Salz, Rich > wrote: > > • I submitted a PR [1] for draft-ietf-tls-md5-sha1-deprecate to move > the recommended IANA registry entries for rsa_pkcs1_sha1 and ecdsa_sha1 in > the Signature Scheme registry from Y to N. This change can be incorporated > with any updates from the AD review. > > Yes yes yes. > > Or no no no? > > I think it is remove the “Y” and leave blank, right? > ___ > 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] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate
On Fri, Sep 18, 2020 at 10:28 AM Sean Turner wrote: > Also, should we be adding “_legacy” to the names of the code points as was > done for rsa_pkcs1_sha256_legacy by: > https://www.ietf.org/archive/id/draft-davidben-tls13-pkcs1-00.txt? > My inclination is no. We didn't go about renaming the huge mess of TLS cipher suites or anything else that I remember. The "_legacy" suffix in that draft has a slightly different meaning (perhaps I should have picked a different name). The existing rsa_pkcs1_sha256 code points from TLS 1.2 were carried over into TLS 1.3 but with a subsetted meaning. In TLS 1.2, rsa_pkcs1_sha256 advertises both TLS and X.509 capabilities, but in TLS 1.3 it advertises only X.509 capabilities. rsa_pkcs1_sha256 is undefined for a TLS CertificateVerify because we took PKCS#1 v1.5 out. So, in order for TLS 1.3 servers to opt into accepting PKCS#1 v1.5 signatures in CertificateVerify, the draft needed to define new code points with a CertificateVerify capability. rsa_pkcs1_sha256_tls1_3_certificate_verify_for_legacy_clients was a mouthful, so I just added a "legacy" suffix. :-) David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate
Okay, I am find with the Y->N change. Nick, Yoav? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
ekr> Taking a step back from details, ISTM that the whole design of this ekr> document is antithetical to extensibility: I agree. It was my first reaction as well. I then had another thought: there are dozens of entities out there that want to do this regardless, enough that it broke the TLS version system requiring the hack. (Does that hack have a name?) We can call them stupid, or we can try to understand their point of view, and try to help them be less stupid. ekr> TLS is a protocol with a number of extension points. What this document ekr> does is allow an endpoint to restrict its use of a certain set of ekr> extension points. However, the language provided here is insufficiently ekr> rich to allow the client to properly describe the use of those ekr> points. assuming that some language could be provided that was sufficiently rich, would your objection continue to stand? ekr> As a concrete example: for extensions the model knows about ekr> (e.g., supported_versions) you can indicate the contents of the ekr> extension, but for extensions the model does not know about (e.g., ECH) ekr> you cannot. That means that you're either stuck with allowing anything ekr> in those extensions (which means that your filtering effectiveness is ekr> reduced) or you don't allow those extensions, in which case you create ossification. ekr> As a thought example, consider a hypothetical TLS 1.4 which decided to ekr> adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated ekr> CH/SH in extensions in a stereotyped outer CH/SH. The system described ekr> here would be unable to do anything useful with that, which creates ekr> pressure to block TLS 1.4 entirely, which obviously is not awesome. I believe that without a mechanism described in this document, many enterprises may conclude that they need to block TLS 1.3. ekr> If we want to pursue this kind of idea -- and I'm not at all sure we ekr> should -- ISTM that rather than trying to invent some new DSL for ekr> filtering TLS we allow the client (who by hypothesis is trusted as to ekr> what it will generate) to provide a general program that the middlebox ekr> can interpret that will describe what it will do. For instance, you ekr> could provide a WASM file which gets fed the CH and just says "this is ekr> me" or "this doesn't look like me". That way we don't need to continue ekr> extending the language here whenever TLS evolves. Note that that doesn't ekr> prohibit having a language like this as a programming convenience, but ekr> it wouldn't restrict the semantics of what you could say about the ekr> connection. We don't have to have the client provide it, it can be encoded by the manufacturer in the MUD file, assuming that it depends upon the model, not some local decision in the client. The idea of having a WASM file is an interesting one, but being an executable of a sort, it has other security problems. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
On Fri, Sep 18, 2020 at 3:12 PM Michael Richardson wrote: > > ekr> Taking a step back from details, ISTM that the whole design of this > ekr> document is antithetical to extensibility: > > I agree. It was my first reaction as well. > I then had another thought: there are dozens of entities out there that > want > to do this regardless, enough that it broke the TLS version system > requiring > the hack. (Does that hack have a name?) > There are actually two things here: 1. Changing the version system -- this was done mostly to accommodate broken servers. 2. Compatibility mode (hiding the HRR, fake CCS, etc.) -- this was designed to work around broken middleboxes. We can call them stupid, or we can try to understand their point of view, > and > try to help them be less stupid. > I don't believe that my note calls them stupid. In any case, ISTM that the design principle that both 1.3 and QUIC have converged on is to opaque-ify as much of the handshake as possible, thus discouraging passive protocol enforcement of this kind. ekr> TLS is a protocol with a number of extension points. What this document > ekr> does is allow an endpoint to restrict its use of a certain set of > ekr> extension points. However, the language provided here is > insufficiently > ekr> rich to allow the client to properly describe the use of those > ekr> points. > > assuming that some language could be provided that was sufficiently rich, > would your objection continue to stand? > I think it's quite likely that that language would have to be Turing-complete. I note that the current language is already very complicated and yet insufficiently rich. > ekr> As a concrete example: for extensions the model knows about > ekr> (e.g., supported_versions) you can indicate the contents of the > ekr> extension, but for extensions the model does not know about (e.g., > ECH) > ekr> you cannot. That means that you're either stuck with allowing anything > ekr> in those extensions (which means that your filtering effectiveness is > ekr> reduced) or you don't allow those extensions, in which case you > create ossification. > > ekr> As a thought example, consider a hypothetical TLS 1.4 which decided to > ekr> adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated > ekr> CH/SH in extensions in a stereotyped outer CH/SH. The system described > ekr> here would be unable to do anything useful with that, which creates > ekr> pressure to block TLS 1.4 entirely, which obviously is not awesome. > > I believe that without a mechanism described in this document, many > enterprises may conclude that they need to block TLS 1.3. > Perhaps you mean some hypothetical TLS 1.4? There is already very widespread deployment of TLS 1.3 for HTTPS and blocking it would cause breakage of a large number of sites. Perhaps you could safely do it for non-443 ports... > ekr> If we want to pursue this kind of idea -- and I'm not at all sure we > ekr> should -- ISTM that rather than trying to invent some new DSL for > ekr> filtering TLS we allow the client (who by hypothesis is trusted as to > ekr> what it will generate) to provide a general program that the middlebox > ekr> can interpret that will describe what it will do. For instance, you > ekr> could provide a WASM file which gets fed the CH and just says "this is > ekr> me" or "this doesn't look like me". That way we don't need to continue > ekr> extending the language here whenever TLS evolves. Note that that > doesn't > ekr> prohibit having a language like this as a programming convenience, but > ekr> it wouldn't restrict the semantics of what you could say about the > ekr> connection. > > We don't have to have the client provide it, it can be encoded by the > manufacturer in the MUD file, assuming that it depends upon the model, not > some local decision in the client. Sorry, yes. I meant "client" in the sense that the client tells the middlebox what rules to use. Whether it does so directly or by reference to the manufacturer doesn't seem to matter too much for these purposes. > The idea of having a WASM file is an > interesting one, but being an executable of a sort, it has other security > problems. > Well, one always has to worry about the security of processing data one receives from the network, but I'm not sure that the distinction between the kind of DSL we're talking about here and an executable is really that sharp. The argument for WASM or something like it is that there has already been enormous investment in building sandboxed interpreters for it, so one gets to inherit all of that effort. This is not, of course, to say that the WASM sandbox will never have vulnerabilities,but one can generally not say that about any software. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
