Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
Hi Nick, Please see inline On Wed, 16 Sep 2020 at 06:00, Nick Harper wrote: > I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft. > > The grease_extension parameter shouldn't exist, and there should be no > special handling for GREASE values. GREASE doesn't need to be mentioned in > this draft, except to say that a client may send values (cipher suites, > extensions, named groups, signature algorithms, versions, key exchange > modes, ALPN identifiers, etc.) that are unknown to the middlebox and that > the middlebox MUST NOT reject connections with values unknown to the > middlebox. > The grease_extension parameter in the YANG model is a "boolean" type to indicate whether the GREASE values are offered by the client or not. The MUD YANG model does not convey the GREASE values. > (This can be stated without mentioning GREASE specifically.) > > There is also an issue where this draft does not describe how an observer > identifies whether a TLS ClientHello is compliant with a MUD profile. > For example, an alert could be triggered to quarantine and remediate the compromised device, and will update the draft to clarify. -Tiru > > On Tue, Sep 15, 2020 at 4:58 PM Watson Ladd wrote: > >> On Tue, Sep 15, 2020, 9:10 AM Eliot Lear >> wrote: >> > >> > >> > >> > My concern is not with "new extensions" per se. The hidden assumption >> here is that "extensions" are the only way TLS can evolve. In fact, future >> TLS versions are not constrained to evolve in any particular way. For >> example, future versions can introduce entirely new messages in the >> handshake, or remove messages that are currently visible in the handshake. >> QUIC is arguably just an extreme version of this observation. >> > >> > >> > I understand. I used TLS extensions merely as an example. >> >> There is no reason that a firewall should expect to parse TLS 1.4. TLS >> 1.3 had to go through significant hoops due to middleboxes that >> assumed they could see into everything like it was 1.2. This easily >> added a year to the development time. The final hunt for incompatible >> devices involved attempting to purchase samples, with no real >> guarantee that they would find an intolerant device. Encouraging this >> sort of behavior is a bad idea IMHO, as it will substantially burden >> the TLS WG when designing TLS 1.4 in all sorts of unexpected ways. >> >> > >> > >> > Even within the realm of ClientHello extensions, there is significant >> inflexibility here. For example, consider the handling of GREASE >> extensions. GREASE uses a variety of reserved extension codepoints, >> specifically to make sure that no entity is attempting to restrict use of >> unrecognized extensions. This proposal therefore has to add a flag >> declaring whether the client uses GREASE, because otherwise the set of >> extensions is dynamic, and the number of potential codepoints is >> impractically large. Any change to the way GREASE selects and rotates >> extension codepoints would therefore require a revision of this YANG model >> first. There has also been discussion of adding GREASE-type behavior to >> the "supported_versions" extension; that would similarly require a revised >> YANG model here. >> > >> > >> > Probably greasing is something that needs a certain special handling. >> Indeed that’s a form of fingerprinting (greases field XYZ). >> >> The whole point of grease is keeping extensions open. Coding special >> handling defeats the purpose. >> >> Sincerely, >> Watson Ladd >> >> > >> > Eliot >> >> ___ >> 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] 2nd WGLC for Delegated Credentials for TLS
On Mon, Sep 14, 2020 at 11:11:03AM -0400, Daniel Migault wrote: > Hi Nick, > > Thanks for the response and I apologize for my delayed response. However I > still have two major concerns regarding the current proposed text: > > Mentioning keyless as the only solution complementary to DC still seems to > me technically inaccurate. With KeylessSSL, the key server receives a hash > based on randoms and ECDH parameters. The hash used in TLS 1.3 is different > than in TLS 1.2 - when hashes are involved in the signature scheme - so > Keyless would not work in this case - at least as far as I understand - and > significant changes are need to make it work in TLS 1.3. The way I understand Keyless is as generic mechanism. The reason why the Keyless paper did not discuss TLS 1.3 was that TLS 1.3 was very early draft, and thus in significant flux, when the Keyless paper was published. Extending the signed-DH variant of Keyless to work with TLS 1.3 is straightforward task. And there are already production implementations. > It seems to me technically more accurate to mention the effort performed on > TLS 1.3 with draft-mglt-lurk-tls13 that is working in a TLS 1.3 context. On > the other hand, not mentioning it seems to me misleading. I also think it > is misleading to not mention an effort that addresses the signing oracle > security vulnerabilities associated to keylessSSL, leading to the > impression that such attacks are inherent to the key server architecture - > with a dedicated section 7.6. I understand, though, > that draft-mglt-lurk-tls13 is not a commercial product and still an > ongoing effort. > So far - unless I am missing them - I have not seen any technical > justification for not mentioning that justify the single mention of > keylessSSL and temptative of (non technical) procedural explanations do not > seem valid ( see in line ). IIRC, some analysis of Keyless type scheme found some security issues. All but one was associated with RSA variant, and thus not a concern with using TLS 1.3. The remaining one involved interaction with gQUIC. AFAIK, the security issues with gQUIC that led to the problem have been fixed (and iQUIC never had the problem to begin with). And the way TLS 1.3 signatures are constructed, that harmful interaction with gQUIC could trivially be prevented (preventing that interaction with TLS 1.2 is a bit trickier, but still feasible). The section 7.6 stuff is only relevant to the RSA variant. There are solid ways to prevent those issues. For example: 1) Use ECC keys. 2) Use interface which only has message for signed-DH variant. Based on data I have seen, there is virtually no reason to support RSA in TLS 1.2 or 1.3. I do not have seen corresponding data for TLS 1.0 and 1.1. > Another concern I have - at least my understanding of it - is that DC is > subject to downgrade attacks. Typically the TLS operator chooses the > signature used by the DC to authenticate the server and this signature > scheme can be weaker than the signature scheme provided by the CA. This > prevents a content owner to enforce a (strong) level of authentication and > - in the future - the use of deprecated/weak signature schemes. The threat > model here is on the content owner perspective to ensure its website is > strongly authenticated. The fact that the client can remove weak signature > schemes does not seem sufficient as nothing seems to force the client to > only use strong authentication with SignatureSchemeList potentially > appearing in clear. The threat model you seem to refer to is the client to > choose a strong authentication, but I think that is a bit different. The content owner can pick what algorithms he signs DCs for. Say that the content owner has ECDSA P-384 certificate and wants comparable authentication strength. Then he only signs DCs for ECDSA P-384 and Ed448. This way there is no downgrade below 192-bit level. And in case of sudden cryptographic advance reducing strength of some algorithm badly enough, that algorithm can be dropped quickly. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets
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
Re: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets
"Variable-length" and "secret" don't really go together in the same sentence, as your work demonstrates. I would actually go further and strike that text altogether. I don't think it needs to be an open question. That lets us stick with a simple construction. While the public values aren't secret so there's less strong of a guarantee, I'd go even further to drop the length prefixes inside the HybridKeyExchange structure. That saves four bytes on the wire. If someone does want to allocate a codepoint that needs the length prefixes, they can always define it for that code point. (That's another nice thing about using separate code points for separate hybrids rather than generic crypto combinators. We don't have to design for every improbable possibility.) I will note, we did have variable-width public values in DHE, but that caused interop issues and we fixed it in https://github.com/tlswg/tls13-spec/pull/458. David 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] Hybrid key exchange in TLS 1.3 and variable-length secrets
On Wed, Sep 16, 2020 at 12:47 PM David Benjamin wrote: > "Variable-length" and "secret" don't really go together in the same > sentence, as your work demonstrates. I would actually go further and strike > that text altogether. I don't think it needs to be an open question. That > lets us stick with a simple construction. > > While the public values aren't secret so there's less strong of a > guarantee, I'd go even further to drop the length prefixes inside > the HybridKeyExchange structure. That saves four bytes on the wire. If > someone does want to allocate a codepoint that needs the length prefixes, > they can always define it for that code point. (That's another nice thing > about using separate code points for separate hybrids rather than generic > crypto combinators. We don't have to design for every improbable > possibility.) > I see the draft mentions SIKE having both compressed and uncompressed variants as a justification, but that's not a reason for variable-length public values. Any TLS code point using such a KEM should pick a particular encoding so there's just the one mode, in the same way that ECDH keys have both compressed and uncompressed encodings, but RFC8446 picks a single format. (https://tools.ietf.org/html/rfc8446#section-4.2.8.2) Allowing both means we either need a negotiation (so they should have been separate code points), or we end up with a giant interop and complexity mess. > I will note, we did have variable-width public values in DHE, but that > caused interop issues and we fixed it in > https://github.com/tlswg/tls13-spec/pull/458. > > David > > 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] Hybrid key exchange in TLS 1.3 and variable-length secrets
On Wed, Sep 16, 2020 at 07:26:56PM +0300, Nimrod Aviram wrote: > > 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. Searching for newest available versions of finalists/alternates specifications, all have constant output lengths except Kyber (usually 32 octets, but HQC uses 64, and FrodoKEM and SIKE use 16 at Cat1 and 24 at Cat3). Kyber is a bit odd case. The spec uses raw XOF output as key, and the specification does not seem to say anywhere how long the output should be. The reference implementation always uses 32 octets as output length. So none of the finalists/alternates need variable-length secret fields. And with TLS 1.3, due to the way secret is injected into key schedule, a length field would only be strictly needed for injectivity if there are multiple variable-length subkeys. And with regards to TLS 1.2, I would just leave it. Adding PQC to TLS 1.2 is harder than adding PQC to TLS 1.3 (this is definitely not one of those "old versions for free" cases), and TLS 1.2 is pretty much obsolete anyway. -Ilari ___ 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 Sep 16, 2020, at 1:08 PM, Nick Harper wrote: > On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy wrote: > Hi Nick, > > Please see inline > > On Wed, 16 Sep 2020 at 06:00, Nick Harper wrote: > I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft. > > The grease_extension parameter shouldn't exist, and there should be no > special handling for GREASE values. GREASE doesn't need to be mentioned in > this draft, except to say that a client may send values (cipher suites, > extensions, named groups, signature algorithms, versions, key exchange modes, > ALPN identifiers, etc.) that are unknown to the middlebox and that the > middlebox MUST NOT reject connections with values unknown to the middlebox. > > The grease_extension parameter in the YANG model is a "boolean" type to > indicate whether the GREASE values are offered by the client or not. The MUD > YANG model does not convey the GREASE values. > > This is still problematic. > > Unknown values MUST be ignored; GREASE is a mechanism used by endpoints to > check that their peers correctly ignore unknown values (instead of closing > the connection). If a device special-cases GREASE values when processing TLS > messages, that device has completely missed the purpose of GREASE and is > likely to cause interoperability failures when in the future it sees a TLS > message that contains a new extension/cipher suite/etc. that isn't a GREASE > value. > > The IETF should not be encouraging devices to special-case GREASE values. I > can see no use of the grease_extension parameter in the YANG model that does > not involve special-casing GREASE values. Hence it needs to be removed. Yes, that is the better way to handle GREASE: expect Grease from any client, on any TLS value (as Ben pointed out supported_versions may well be Grease'd next). -d ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
Taking a step back from details, ISTM that the whole design of this document is antithetical to extensibility: TLS is a protocol with a number of extension points. What this document does is allow an endpoint to restrict its use of a certain set of extension points. However, the language provided here is insufficiently rich to allow the client to properly describe the use of those points. As a concrete example: for extensions the model knows about (e.g., supported_versions) you can indicate the contents of the extension, but for extensions the model does not know about (e.g., ECH) you cannot. That means that you're either stuck with allowing anything in those extensions (which means that your filtering effectiveness is reduced) or you don't allow those extensions, in which case you create ossification. As a thought example, consider a hypothetical TLS 1.4 which decided to adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated CH/SH in extensions in a stereotyped outer CH/SH. The system described here would be unable to do anything useful with that, which creates pressure to block TLS 1.4 entirely, which obviously is not awesome. If we want to pursue this kind of idea -- and I'm not at all sure we should -- ISTM that rather than trying to invent some new DSL for filtering TLS we allow the client (who by hypothesis is trusted as to what it will generate) to provide a general program that the middlebox can interpret that will describe what it will do. For instance, you could provide a WASM file which gets fed the CH and just says "this is me" or "this doesn't look like me". That way we don't need to continue extending the language here whenever TLS evolves. Note that that doesn't prohibit having a language like this as a programming convenience, but it wouldn't restrict the semantics of what you could say about the connection. -Ekr On Wed, Sep 16, 2020 at 1:09 PM Nick Harper wrote: > > > On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy wrote: > >> Hi Nick, >> >> Please see inline >> >> On Wed, 16 Sep 2020 at 06:00, Nick Harper wrote: >> >>> I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft. >>> >>> The grease_extension parameter shouldn't exist, and there should be no >>> special handling for GREASE values. GREASE doesn't need to be mentioned in >>> this draft, except to say that a client may send values (cipher suites, >>> extensions, named groups, signature algorithms, versions, key exchange >>> modes, ALPN identifiers, etc.) that are unknown to the middlebox and that >>> the middlebox MUST NOT reject connections with values unknown to the >>> middlebox. >>> >> >> The grease_extension parameter in the YANG model is a "boolean" type to >> indicate whether the GREASE values are offered by the client or not. The >> MUD YANG model does not convey the GREASE values. >> >> > This is still problematic. > > Unknown values MUST be ignored; GREASE is a mechanism used by endpoints to > check that their peers correctly ignore unknown values (instead of closing > the connection). If a device special-cases GREASE values when processing > TLS messages, that device has completely missed the purpose of GREASE and > is likely to cause interoperability failures when in the future it sees a > TLS message that contains a new extension/cipher suite/etc. that isn't a > GREASE value. > > The IETF should not be encouraging devices to special-case GREASE values. > I can see no use of the grease_extension parameter in the YANG model that > does not involve special-casing GREASE values. Hence it needs to be removed. > ___ > 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
