Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, 4 Apr 2018, Eric Rescorla wrote: HPKP had a TTL and yet as a practical matter, people found it very problematic. And, of course, if you're concerned with hijacking attacks, the hijacker will just advertise a very long TTL. By publising DANE records with either a TLSA record or a denial of existence proof, you can override any longterm TTL. If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension containing a valid NSEC proof of non-existence overrides the previous TTL/PIN. In fact, this is one of the reasons the WG should decide to fix the current draft to include proofs of denial of existence. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, 4 Apr 2018, Eric Rescorla wrote: 1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's a pain). This rationale was stronger back before Let's Encrypt, but I suppose some people may still feel that way. 2. Restrictive: To protect yourself from compromise of the WebPKI. Yes, if your motivation is #2, then the flow you suggest is a real problem, but it's not a problem for #1. While not an author of this document, I'd understood it's primary motivation to be #1, and that's what Richard's earlier notes have said as well. The primary use case of the author's is not relevant. The document is a working group document, and people who have contributed to this document from the start also have valid use cases. For example, I proposed to use the DNS wire format early on and the WG made that change. My use case was never to create a "DANE or WebPKI is enough" security model, as I do not think that model helps anyone. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, 5 Apr 2018, Richard Barnes wrote: And just to be clear, by "downgrade attack", you mean "normal PKI authentication that we rely on today". There's nothing in here that degrades security You mean other then LetsEncrypt destroying the ecosystem and leading to a "one key to rule them all" situation? The webpki is changing dramatically. The amount of CAB/forum violations seems to be increasing, partially as a result of these violations getting exposed by certificate transparancy and perhaps partially because of the financial strain caused by the free LetsEncrypt. Allowing people to deploy another PKI is not harmful - forcing people to stick with the webpki could prove harmful. That doesn't mean there's not still some utility to be had. Your tls-extension use case can be supported regardless of the outcome of this consensus call. That is not at stake today. Other people's valid use cases are the ones that are at stake now. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, 4 Apr 2018, Eric Rescorla wrote: The motivation for opportunistically using this is to be able to incrementally deploy DANE for HTTPS (and browsers). Without that it won't get deployed at all for HTTPS. I don't see how this is responsive to the concern that this technique will be used for hijacking. To hijack a DANE TLSA record, an attacker has to take over the DNS domain. Controlling the DNS is equally fatal for the webpki, as you can just ACME a new certificate at that point. So the hijacking case is not made worse at all. But the compromise/coercion of only 1 of 600+ (sub)CA's is actually protected against, making DANE a stronger authentication alternative. Additionally, in the case of forced domain transfer in relation to an ownership dispute being litigated, the DANE based pinning is actually superior to any other kind of pinning, because it gives the (new) domain owner full control to cancel any outstanding long term pins distributed by the old/previous/malicious owner. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT)
Martin Vigoureux has entered the following ballot position for draft-ietf-tls-record-limit-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ -- COMMENT: -- Hello, I'm not a TLS expert so please disregard if this is irrelevant. Document says: Clients that depend on having a small record size MAY continue to advertise the "max_fragment_length". Do you mean: Clients that depend on having a small record size MAY continue to advertise the "max_fragment_length" *only*. If so, what would be the behaviour of a server that supports both "max_fragment_length" and "record_size_limit" in that situation? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 05, 2018 at 02:46:12AM -0400, Viktor Dukhovni wrote: > > > > On Apr 4, 2018, at 1:50 PM, Joseph Salowey wrote: > > > > A) Recommendation of adding denial of existence proofs in the chain > > provided by the extension > > B) Adding signaling to require the use of this extension for a period of > > time (Pinning with TTL) > > C) Both > > Therefore, the real choice before us is (C) or not (C), the choices of (A) > alone or (B) > alone are unsound half-measures. I agree that both (A) and (B) are bad idea, while (C) is sound idea. > (C) is essentially STS for dane chains over TLS with downgrade protection > after first > contact, and imposes no burden on the present implementors. If they were > willing to > implement without a pin or denial of existence, they can ignore the pin TTL > and never > transmit denial of existence (which their clients would not expect to > process). If one wants to save bandwidth in "cancel pin" case, one could add a flag into request that tells the server if it should transmit DoE or not (if it has actual chain, that should be transmitted anyway). That way, the cancel would only need to be transmitted once to each client, instead of potentially multiple times, and clients that do not support pinning would not waste downstream bandwidth downloading cancels they would ignore anyway. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT)
On Thu, Apr 5, 2018 at 7:31 PM, Martin Vigoureux wrote: > Hello, I'm not a TLS expert so please disregard if this is irrelevant. > Document says: >Clients that depend on having a small record size MAY continue to >advertise the "max_fragment_length". > > Do you mean: >Clients that depend on having a small record size MAY continue to >advertise the "max_fragment_length" *only*. It's "also". The idea being that if you aren't sure if the server supports the new thing, you might offer the old thing in addition to the new thing in the hopes that if the new thing isn't supported, the old thing might be. > If so, what would be the behaviour of a server that supports both > "max_fragment_length" and "record_size_limit" in that situation? If you don't include record_size_limit, you can't use it. If the client includes both, then the text from the preceding paragraph applies: "A server that supports the record_size_limit extension MUST ignore a max_fragment_length that appears in a ClientHello if both extensions appear." ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 5, 2018 at 2:02 AM, Paul Wouters wrote: > On Wed, 4 Apr 2018, Eric Rescorla wrote: > > HPKP had a TTL and yet as a practical matter, people found it very >> problematic. >> And, of course, if you're concerned with hijacking attacks, the hijacker >> will >> just advertise a very long TTL. >> > > By publising DANE records with either a TLSA record or a denial of > existence proof, you can override any longterm TTL. > > If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension > containing a valid NSEC proof of non-existence overrides the previous > TTL/PIN.' Thanks. This is a good point that I agree does not apply to HPKP. However, that doesn't mean that hijacking isn't a problem (though I agree a less serious one). If I have no provisions for DNSSEC at all and the attacker does pin hijacking I could be offline for hours to days while I figure out how to get and serve them. -Ekr > In fact, this is one of the reasons the WG should decide to fix the > current draft to include proofs of denial of existence. > > Paul > > > ___ > 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 5, 2018 at 2:06 AM, Paul Wouters wrote: > On Wed, 4 Apr 2018, Eric Rescorla wrote: > > 1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's >> a pain). This rationale was stronger back before Let's Encrypt, but >> I suppose some people may still feel that way. >> >> 2. Restrictive: To protect yourself from compromise of the WebPKI. >> >> Yes, if your motivation is #2, then the flow you suggest is a real >> problem, >> but it's not a problem for #1. While not an author of this document, I'd >> understood it's primary motivation to be #1, and that's what Richard's >> earlier notes have said as well. >> > > The primary use case of the author's is not relevant. The document is a > working group document, and people who have contributed to this document > from the start also have valid use cases. > Of course. I'm merely responding here to the claim that the document is useless as-is. -Ekr > For example, I proposed to use the DNS wire format early on and the WG > made that change. My use case was never to create a "DANE or WebPKI is > enough" security model, as I do not think that model helps anyone. > > Paul > > > ___ > 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] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT)
Martin, thanks for the quick reply. That clarifies. I asked because the paragraph above that sentence somehow already implies that clients may continue advertise the "max_fragment_length" (at least that's ow I understand it), so I felt that this sentence must mean something different. -m Le 2018-04-05 à 12:28, Martin Thomson a écrit : On Thu, Apr 5, 2018 at 7:31 PM, Martin Vigoureux wrote: Hello, I'm not a TLS expert so please disregard if this is irrelevant. Document says: Clients that depend on having a small record size MAY continue to advertise the "max_fragment_length". Do you mean: Clients that depend on having a small record size MAY continue to advertise the "max_fragment_length" *only*. It's "also". The idea being that if you aren't sure if the server supports the new thing, you might offer the old thing in addition to the new thing in the hopes that if the new thing isn't supported, the old thing might be. If so, what would be the behaviour of a server that supports both "max_fragment_length" and "record_size_limit" in that situation? If you don't include record_size_limit, you can't use it. If the client includes both, then the text from the preceding paragraph applies: "A server that supports the record_size_limit extension MUST ignore a max_fragment_length that appears in a ClientHello if both extensions appear." ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 5, 2018, at 9:33 AM, Eric Rescorla wrote: > > However, that doesn't mean that hijacking isn't a problem (though I agree a > less > serious one). If I have no provisions for DNSSEC at all and the attacker does > pin hijacking I could be offline for hours to days while I figure out how to > get > and serve them. Perhaps you did not see my explanation of why the pin imposes no obligation beyond supporting the extension in the server software. A server for an unsigned domain can just serve denial of existence of the domain's (or a parent's) DS record. So you don't need to "get and serve them", you just need to forward whatever is the true data in DNS about the server's domain. Only the capability to present the actual DNS chain is required. * If server's zone is not DNSSEC-signed, forward NSEC records showing existence of NS and non-existence of DS at or above the requested: _443._tcp.server-fqdn.example domain and the requisite signatures up to the root. * If server's zone is DNSSEC-signed, but no TLSA records are present, serve NSEC records proving non-existence (or NODATA) of the requested _443._tcp.server-fqdn.example IN TLSA ? records and the requisite signatures up to the root. * If the server's zone is DNSSEC-signed, and TLSA records are present, serve the requested TLSA records along with the requisite signatures up to the root. All three of these would be obtained and cached (up to most of the advertised TTL) in the same way from a suitable resolver that supports chain queries, it is up to that resolver to return the appropriate response each of the above cases, the server can treat the data as opaque, modulo determining the time for which it may cache the response so that the chain need not be re-fetched for each client connection. If one is worried about hijack by someone who can cause the domain to be signed with TLSA records published (so as to set a non-zero pin), then one might be motivated to have server software that is capable of returning the extension. Just as with STS one might need software that supports TLS if the hijacker deployed STS. I don't think that such hijacking is a major risk, but if that risks drives adoption of the extension (without any other changes in tbe domain's practices wrt. DNSSEC or DANE adoption) all the better. :-) The domain might need the extension some day for more than just hijack recovery, and it will already be available. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 5, 2018 at 7:08 AM, Viktor Dukhovni wrote: > > > > On Apr 5, 2018, at 9:33 AM, Eric Rescorla wrote: > > > > However, that doesn't mean that hijacking isn't a problem (though I > agree a less > > serious one). If I have no provisions for DNSSEC at all and the attacker > does > > pin hijacking I could be offline for hours to days while I figure out > how to get > > and serve them. > > Perhaps you did not see my explanation of why the pin imposes no > obligation beyond > supporting the extension in the server software. A server for an unsigned > domain > can just serve denial of existence of the domain's (or a parent's) DS > record. > Yes, so quite possibly I need to upgrade my entire server farm, which might be running on some software which has no version which implements this extension. This could be an enormous effort. -Ekr - > > So you don't need to "get and serve them", you just need to forward > whatever is > the true data in DNS about the server's domain. Only the capability to > present > the actual DNS chain is required. > > * If server's zone is not DNSSEC-signed, forward NSEC records > showing > existence of NS and non-existence of DS at or above the > requested: > > _443._tcp.server-fqdn.example > > domain and the requisite signatures up to the root. > > * If server's zone is DNSSEC-signed, but no TLSA records are > present, serve > NSEC records proving non-existence (or NODATA) of the requested > > _443._tcp.server-fqdn.example IN TLSA ? > > records and the requisite signatures up to the root. > > * If the server's zone is DNSSEC-signed, and TLSA records are > present, serve > the requested TLSA records along with the requisite signatures > up to the root. > > All three of these would be obtained and cached (up to most of the > advertised TTL) in > the same way from a suitable resolver that supports chain queries, it is > up to that > resolver to return the appropriate response each of the above cases, the > server can > treat the data as opaque, modulo determining the time for which it may > cache the > response so that the chain need not be re-fetched for each client > connection. > > If one is worried about hijack by someone who can cause the domain to be > signed > with TLSA records published (so as to set a non-zero pin), then one might > be > motivated to have server software that is capable of returning the > extension. > Just as with STS one might need software that supports TLS if the hijacker > deployed STS. I don't think that such hijacking is a major risk, but if > that > risks drives adoption of the extension (without any other changes in tbe > domain's practices wrt. DNSSEC or DANE adoption) all the better. :-) > The domain might need the extension some day for more than just hijack > recovery, > and it will already be available. > > -- > Viktor. > > ___ > 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 5, 2018, at 10:20 AM, Eric Rescorla wrote: > > > Yes, so quite possibly I need to upgrade my entire server farm, which might > be running > on some software which has no version which implements this extension. This > could > be an enormous effort. Yes, module hijack. The same applied with STS, if the server farm had no TLS support, or insufficient capacity to handle the load with TLS. This is not substantially different, other than that TLS support is fairly mainstream now. Note that the hijack would also need obtain WebPKI certificates (as I would expect DANE for browsers to insist on the restrictive PKIX-TA(0) / PKIX-EE(1)). So the that would be a full takeover of the domain, and the affected clients would have to have visited the hijacked site during the time it was controlled by the malicious party. Note also that clients that support the extension will also be rare for some time, so the impact of any hijack that improbably pins the extension will be modest. So, if some users running early adopter browsers that support the extension have to manually clear the pin after a domain hijack, and visiting the hijacked site, potentially disclosing sensitive information to the wrong party, etc. then becoming aware of that when the browser warns them about missing extension support seems like a feature and not a bug. They can and probably should contact the legitimate site's help desk and figure out what to do to secure their account, change passwords, ... This scenario is not impossible, but a rather low risk, and would initially, as server support ramps up, affect few users. The pin can be cleared by the user in such a situation, and having the user be aware of the fact that he/she visited a hijacked site is not a bad thing. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 05, 2018 at 06:33:10AM -0700, Eric Rescorla wrote: > On Thu, Apr 5, 2018 at 2:02 AM, Paul Wouters wrote: > > On Wed, 4 Apr 2018, Eric Rescorla wrote: > >> HPKP had a TTL and yet as a practical matter, people found it very > >> problematic. > >> And, of course, if you're concerned with hijacking attacks, the > >> hijacker will just advertise a very long TTL. > > > > By publising DANE records with either a TLSA record or a denial of > > existence proof, you can override any longterm TTL. > > > > If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension > > containing a valid NSEC proof of non-existence overrides the > > previous TTL/PIN.' > > Thanks. This is a good point that I agree does not apply to HPKP. > > However, that doesn't mean that hijacking isn't a problem (though I > agree a less serious one). If I have no provisions for DNSSEC at all > and the attacker does pin hijacking I could be offline for hours to > days while I figure out how to get and serve them. I've been calling this pin-to-DANE because it's short, but, really, it's pin-to-using-this-extension. You can use this extension even if your domain is not signed because the proof that it isn't signed would be delivered in this extension. I believe the only way pinning to this extension can cause the hijacking you propose is if the root zone stops being signed as then there would be no way to prove that you're no longer using DANE :) Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 04, 2018 at 08:39:37PM -0700, Eric Rescorla wrote: > On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams wrote: > > Either way it's the same impact: you cannot roll that key over. > > > > Whereas with pin-to-DANE there's no such problem. I thought I made that > > clear. > > Yes, I agree that you're relying on a different guarantee from your > parent zone, I just don't think it's particularly obvious that that > guarantee is easier to ensure, for the reasons I indicated previously. Sure it is. As long as the root zone is signed you can use this extension and prove that you are / are not using DANE. > > > And, of course, if you're concerned with hijacking attacks, the > > > > > hijacker will just advertise a very long TTL. > > > > > > > > But it's a TOFU-ish thing. The server impersonator has to have the > > > > right timing or else be detected -- that's very risky for them, and a > > > > deterrent to even trying. It's not fool-proof, but it's not nothing > > > > either. > > > > > > Given that the motivation for this kind of hijacking was generally > > > expected to be vandalism or ransom, this doesn't seem very comforting. > > > > The motivation for opportunistically using this is to be able to > > incrementally deploy DANE for HTTPS (and browsers). Without that it > > won't get deployed at all for HTTPS. > > I don't see how this is responsive to the concern that this technique will > be used for hijacking. You're right. I believe this has been answered now separately by others, and also by me. This is not a pin-to-DANE feature we're asking for, but a pin-to-using-this-extension. I shouldn't have called it pin-to-DANE, but I did because it's short -- short, but not sufficiently pithy :( Now, it's true that an impersonator could force you to use this extension when you were not ready to, and that's a DoS, though an easy one to fix, relatively. I'll take that DoS over a downgrade attack. We could mitigate the DoS by saying that the pin TTL must be coerced to zero (or maybe 1) if the extension only bore an authenticated denial of existence. I would prefer to not have to do this, but I'd accept it. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 5, 2018, at 10:54 AM, Nico Williams wrote: > > We could mitigate the DoS by saying that the pin TTL must be coerced to > zero (or maybe 1) if the extension only bore an authenticated denial of > existence. I would prefer to not have to do this, but I'd accept it. When we get past this consensus call, and get to craft the actual text describing the pin TTL, I would expect a non-zero PIN to only be possible when proving TLSA records. A denial of existence should not be able to set a new pin TTL, and should clear any previous pin TTL. If DANE is not actually deployed, there's little reason to pin the extension, and clearing the pin via denial of existence is a useful mechanism. A client might then lose access to continued denial of existence until it again sees actual TLSA records with a non-zero pin, but that seems OK to me. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24]
Eric Rescorla writes: > I guess there might be some intermediate category 1.5 that's kind of in > production so you don't want to print out complete logs, but you'd like > more detail than you would probably want to expose in general, but my > experience is that that's not super-common. My expectation is that the useful case is when there *aren't* any logs, or what logging is done does not tell the specific reasons that particular interactions were rejected. That's pretty common in SIP systems. Of course, anything like this would be an extension. But would it be reasonable for one endpoint to present a "debug password" in its request which, if it matched the debug password set in the other endpoint, would cause the other endpoint to provide fuller error information? That would allow a "debug window" that could be exploited only between endpoints that had some sort of administrative coordination. Dale ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24
Bill Frantz writes: > We have always avoided the long form error messages in TLS > because they can be of great help to attackers as well as > debuggers. I think this objection is much weaker if we write the > long form error messages into a log that is kept with other > server logs. I'd not considered textual messages. What struck me is that the draft has dozens, maybe more than 100, conditions that must be satisfied, and only a few different error codes. It strikes me that each particular rule could be assigned an error number, so an implementation could point out which of the dozens of rules was violated in a particular handshake. Dale ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24
> On Apr 1, 2018, at 10:37 AM, Salz, Rich wrote: > >> Possibly, if you consider being able to say "Invalid length encoding in >preferred-ECC-curves extension" in Tswana is mission-critical to debugging > a >TLS handshake failure. > > I so love your messages, Peter. Honestly I do. > > Perhaps not Tswana, but perhaps China may care to pick a counter-example. For debugging messages, I'm with Peter, they'll only be implemented if they're simple enough to support. I can't see having to have localization files on the server for debug messages that might be requested by a client is some other locale and only when debug is enabled, and the consumer is a developer and not an end-user. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
