Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
On Mon, Nov 05, 2018 at 09:00:29AM -0500, Viktor Dukhovni wrote: > > On Nov 5, 2018, at 8:01 AM, Benjamin Kaduk wrote: > > > > Once we start talking about pinning of any sort, we move from this > > extension just being "transport some DNS records" into conveying some > > sort of additional semantics. > > Transporting some bits *always* carries additional semantics, otherwise Of course! But if we don't precisely specify those semantics, we expect to get DISCUSS positions at IESG evaluation (as "not interoperably implementable"). > why carry the bits. For example, already in -07 there is clear text > specifying that the transported records can be cached for their DNS TTL, > and that once delivered DANE records should not be ignored on failure. [...] > That rather looks like semantics to me, much more than transport some bits. Is it new semantics for this TLS extension, or just the semantics of "you have a DANE record; this is what you do with it"? > > It seems that we have not really had a structured discussion about what > > semantics and information flows we might or might not want to convey in > > this extension (in one or both directions!), and I'm reluctant to consider > > adding such semantics without such a discussion. > > I really don't think that at this juncture it is productive to wipe the > slate clean and consider all possible proposals, even ones that nobody > has put forward as yet. Why would we want to do that. There is clearly When we do work at the IETF, proposals are not presented as a "take it or leave it" option -- usually, they are starting points for further analysis and discussion: "is this optimal?", "is it better if we tweak it in this way?", etc. I am presenting a framework in which to try to answer these questions, starting from the proposal on the table. In other words, I am pointing out that there is a process step that needs to happen before this draft can be published. This need not start from a "clean slate", but we do need to be confident that we understand what we are publishing. > just one primary contentious issue to resolve, and I rather think your > train of thought is a distraction from the issue at hand. The IETF process requires reaching a consensus understanding of the technical facts of an issue. My train of thought is an effort to seek that understanding in the area of downgrade countermeasures, since in my judgement it has not been achieved by the previous WG discussions. If we have no WG consensus understanding of pinning, we cannot publish pinning. That could mean not publishing at all, or publishing something that lacks pinning. The latter would of course not preclude other work on pinning by interested parties. > > If we accept the premise that the intention of DANE as relevant in this > > space is to allow the server to convey to the client the server's > > preferences for how the client should authenticate the server, we may also > > want to consider the case where a server operator wants to eventually get > > to a DANE-only state where it can ignore the web PKI. > > Nobody is looking for this. There's no point. WebPKI certificates are > free (and worth every penny). DANE adoption is far too light to even > begin to contemplate abandoning WebPKI, and we're probably two decades > away from being able to do that, by which point the quantum computer > apocalypse may have made many of the current designs moot. That's good input; thanks. > > (There may not be > > many or any servers that actually end up wanting to do this, but it's not > > unreasonable to consider the possibility.) > > It seems unreasonable to me, because no such signalling was for example > proposed for raw public keys or various PSK methods, etc. And of course > the server operator can log the use of the extension and draw conclusions > about client support based on that, and the overall technology landscape. > There's no need to include this in the discussion. The chairs should feel free to shut this down if needed. But I'll note that the server's logging is not going to get any signal from clients that can get DANE records via their normal resolver, with the current proposal. > > Similarly, the server may want to indicate things like: > > > > (a) the server wants to be authenticated via DANE (yes, this is just the > >contents of the DNS) > > And any client with a decent network environment can just query the > DNS directly, and never use the extension and have the record hot > in the local cache. So there's no need for anything too complicated > here. We just need to provide as much of the downgrade-resistance > that DNSSEC gives automatically, also to clients that for some time I think I'm confused about what you mean by "the downgrade-resistance that DNSSEC gives automatically". > will be able to do DNSSEC. > > > I deliberately am not trying to come to a conclusion in this message, as I > > am not confident that I have even come up with all the p
Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
My question would be "what will the HTTP community do if they find this whole process unwieldy and long"? Answer They will come up with a solution that does nothing with DANE. is that an excuse to do something less than perfect for the better good, or do we live in the world of smug satisfaction of being perfect? Sorry, from reading this discussion that's my simple minded view. Tim On Tue, Nov 6, 2018 at 11:07 PM Benjamin Kaduk wrote: > On Mon, Nov 05, 2018 at 09:00:29AM -0500, Viktor Dukhovni wrote: > > > On Nov 5, 2018, at 8:01 AM, Benjamin Kaduk wrote: > > > > > > Once we start talking about pinning of any sort, we move from this > > > extension just being "transport some DNS records" into conveying some > > > sort of additional semantics. > > > > Transporting some bits *always* carries additional semantics, otherwise > > Of course! But if we don't precisely specify those semantics, we expect > to get DISCUSS positions at IESG evaluation (as "not interoperably > implementable"). > > > why carry the bits. For example, already in -07 there is clear text > > specifying that the transported records can be cached for their DNS TTL, > > and that once delivered DANE records should not be ignored on failure. > [...] > > That rather looks like semantics to me, much more than transport some > bits. > > Is it new semantics for this TLS extension, or just the semantics of "you > have a DANE record; this is what you do with it"? > > > > It seems that we have not really had a structured discussion about what > > > semantics and information flows we might or might not want to convey in > > > this extension (in one or both directions!), and I'm reluctant to > consider > > > adding such semantics without such a discussion. > > > > I really don't think that at this juncture it is productive to wipe the > > slate clean and consider all possible proposals, even ones that nobody > > has put forward as yet. Why would we want to do that. There is clearly > > When we do work at the IETF, proposals are not presented as a "take it > or leave it" option -- usually, they are starting points for further > analysis and discussion: "is this optimal?", "is it better if we tweak > it in this way?", etc. I am presenting a framework in which to try to > answer these questions, starting from the proposal on the table. > > In other words, I am pointing out that there is a process step that > needs to happen before this draft can be published. This need not start > from a "clean slate", but we do need to be confident that we understand > what we are publishing. > > > just one primary contentious issue to resolve, and I rather think your > > train of thought is a distraction from the issue at hand. > > The IETF process requires reaching a consensus understanding of the > technical facts of an issue. My train of thought is an effort to seek > that understanding in the area of downgrade countermeasures, since in my > judgement it has not been achieved by the previous WG discussions. If > we have no WG consensus understanding of pinning, we cannot publish > pinning. That could mean not publishing at all, or publishing something > that lacks pinning. The latter would of course not preclude other work on > pinning by interested parties. > > > > If we accept the premise that the intention of DANE as relevant in this > > > space is to allow the server to convey to the client the server's > > > preferences for how the client should authenticate the server, we may > also > > > want to consider the case where a server operator wants to eventually > get > > > to a DANE-only state where it can ignore the web PKI. > > > > Nobody is looking for this. There's no point. WebPKI certificates are > > free (and worth every penny). DANE adoption is far too light to even > > begin to contemplate abandoning WebPKI, and we're probably two decades > > away from being able to do that, by which point the quantum computer > > apocalypse may have made many of the current designs moot. > > That's good input; thanks. > > > > (There may not be > > > many or any servers that actually end up wanting to do this, but it's > not > > > unreasonable to consider the possibility.) > > > > It seems unreasonable to me, because no such signalling was for example > > proposed for raw public keys or various PSK methods, etc. And of course > > the server operator can log the use of the extension and draw conclusions > > about client support based on that, and the overall technology landscape. > > There's no need to include this in the discussion. > > The chairs should feel free to shut this down if needed. > But I'll note that the server's logging is not going to get any signal > from clients that can get DANE records via their normal resolver, with > the current proposal. > > > > Similarly, the server may want to indicate things like: > > > > > > (a) the server wants to be authenticated via DANE (yes, this is just > the > > >contents of the DNS) > > > > And an
Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
On Tue, Nov 06, 2018 at 10:05:14AM -0600, Benjamin Kaduk wrote: > Of course! But if we don't precisely specify those semantics, we expect > to get DISCUSS positions at IESG evaluation (as "not interoperably > implementable"). Yes, that's why the draft once updated will need to explain the semantics, rationale, limitations, risks, ... of any approach it ultimately takes. > > why carry the bits. For example, already in -07 there is clear text > > specifying that the transported records can be cached for their DNS TTL, > > and that once delivered DANE records should not be ignored on failure. > [...] > > That rather looks like semantics to me, much more than transport some bits. > > Is it new semantics for this TLS extension, or just the semantics of "you > have a DANE record; this is what you do with it"? Well, in -07 there is also a TOFU unilateral pinning proposal, added in a hasty (and little noticed at the end of the original process) attempt to close the gap between promised and viable scope. Otherwise, yes, it mostly tries to parallel what happens when TLSA records are obtained directly from DNS. > > I really don't think that at this juncture it is productive to wipe the > > slate clean and consider all possible proposals, even ones that nobody > > has put forward as yet. Why would we want to do that. There is clearly > > When we do work at the IETF, proposals are not presented as a "take it > or leave it" option -- usually, they are starting points for further > analysis and discussion: "is this optimal?", "is it better if we tweak > it in this way?", etc. I am presenting a framework in which to try to > answer these questions, starting from the proposal on the table. Please pardon my frustration with the recent deadlock. If my objection is excessive, I apologise. That said, I do hope that the discussion will have some focus. * We've made a substantive proposal, explaining both the need for downgrade protection to make the extension more widely applicable, and that risks do not entail anything like an HPKP footgun. * The chairs have summarized the issues, and asked for any substantive objections to the summary... none were made. * I do think it is time to actually settle two basic questions: * Expand the scope to cover existing applications, or rewrite the introduction to say this is a DPRIVE-only extension to TLS, and explain why the scope should not be any wider. * Get past instinctive reactions to pinning the extension (which bears little resemblance to HPKP), and if so move on to figuring out the design parameters. Maximum duration, any gradual scaling to give server operators time to adopt, or no scaling because the risk of hostile pinning is minor and not worth the complexity, ... Yes, of course other topics can also be discussed, but I hope not to the exclusion of moving past the present roadblocks. This is not the end of the process, more of a new beginning, which once progress resumes will leave room for additional considerations. > > And any client with a decent network environment can just query the > > DNS directly, and never use the extension and have the record hot > > in the local cache. So there's no need for anything too complicated > > here. We just need to provide as much of the downgrade-resistance > > that DNSSEC gives automatically, also to clients that for some time > > I think I'm confused about what you mean by "the downgrade-resistance > that DNSSEC gives automatically". When a client using this extension asks the server for a DNSSEC chain, absent any prior commitment by the server, it cannot expect the answer, and not getting one will be the default "normal", not a failure When a validating DNS resolver asks a DNS question it always expects a DNS answer, failing to get an answer, or getting an invalid answer is a failure. Sadly in some captive portals and behind some crippled home CPE equipment, failure is more common than we'd like, but still it is clear that getting no answer, or an invalid answer is a failure. > > I think at this point hypothetical semantics is not a helpful direction. > > I'm sorry you feel that way. We've seen a few participants raise a > specific pinning proposal but they seem to have squelched discussion of > any other pinning options. There have been no substantive alternative pinning proposals. All I've seen is suggesting for a "testing" mode, which is not viable here, as already explained, and out-of-band reporting is also not a good option, an in-band alert would be far simpler and better. Once again sorry if you feel shut down, not my intention, just trying to get some focus on specific refinements or objections, so we can move forward (or not) and if so then entertain more suggested refinements. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
We've had a couple of conference calls to discuss the I-D. One call ended up causing the consensus on the I-D to collapse. The second call ended too soon, but it was not unproductive. Indeed, I think at that call and in the subsequent off-list threads we identified the concerns with pinning: - footgun concerns - hostile abuse concerns Now, I believe we have demonstrated that there is no footgun: whenever you can set the pin, you can also clear the pin. At worst one might first upgrade a server to gain support for the extension, set a pin, then downgrade for some reason and thus footgun -- but the fix is to upgrade again, or not set the pin immediately upon upgrade. We also have a mitigation for upgrade-set-pin-downgrade case (exponential scaling of the pin timer with age of the RFC). The second concern is, IMO, a non-concern, but granting for argument's sake that it might be anyways, our answer to it is that sufficiently far into the future the victim's server will support the extension, thus it will be able to clear a hostile pin, therefore the exponential pin timer scaling idea will give servers time to gain support for the extension before anyone could ever make hostile use of the pin. I believe we have put away those two concerns. If we have not, please say so and explain such that we might (or that we might see the errors of our ways). Are there any other reasons not to accept the proposed pinning scheme? If no one can state any such reasons, why shouldn't we just accept the proposal? Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
On Tue, 6 Nov 2018, Benjamin Kaduk wrote: I think I'm confused about what you mean by "the downgrade-resistance that DNSSEC gives automatically". You cannot filter DNSSEC without the target being aware of being filtered (where filtering == downgrading) Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
On Wed, 7 Nov 2018, Tim Wicinski wrote: My question would be "what will the HTTP community do if they find this whole process unwieldy and long"? Answer They will come up with a solution that does nothing with DANE. They dont need to do anything to not have DANE. They already not have it. is that an excuse to do something less than perfect for the better good, or do we live in the world of smug satisfaction of being perfect? 100% downgradable security is not security. It is not about being smug or perfect. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
[ Quoted text slightly reordered to put the RSA issue first, as that's the main thing I'm trying to get clarity on, and enabling keyUsage enforcement is causing some interoperability issues now... ] > On Nov 5, 2018, at 11:11 PM, Geoffrey Keating wrote: > >> TL;DR: Should TLS client abort DHE-RSA handshakes with a peer >> certificate that *only* lists: >> >>X509v3 Key Usage: >>Key Encipherment, Data Encipherment > > Yes, because in DHE-RSA, the RSA key is used for signing, and this is > an encryption-only key. > > As far as I know there's no similar attack on RSA, but I think this is > not a well-examined area. Since the vast majority of certificates in the wild are RSA, and interoperability is a concern, I'd really like to better understand what risk if any posed if one allows a an *RSA* key with a keyUsage of "keyEncipherment" (seen on some live servers that then do DHE-RSA) to be used for "DigitalSignature"? I am only aware of risks in the converse direction. How unreasonable would it be to be more forgiving and allow *RSA* "DigitalSignature" when the keyUsage indicates otherwise? > It's much more important in the DHE-ECDSA case, because using an > encryption-only EC key for signing can lead to key compromise (IIRC). Does anyone have pointers to references for that? FWIW, I've never seen an encryption-only (ECIES?) ECDSA key, I guess could be intended for CMS... In TLSA there's no ECDS keyEncipherment, only ECDHE and fixed ECDH (obsolete). The first goes with a keyUsage of DigitalSignature, the second with keyAgreement. Knowing how fragile ECDSA tends to be to key recovery on nonce re-use or similar issues, I have no reservations enforcing keyUsage for ECDSA. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] The TLS WG has placed draft-wood-tls-ticketrequests in state "Candidate for WG Adoption"
The TLS WG has placed draft-wood-tls-ticketrequests in state Candidate for WG Adoption (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WGLC for draft-ietf-tls-exported-authenticator
This is the working group last call for the "Exported Authenticators in TLS" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. Please review the document and send your comments to the list by 2359 UTC on 30 November 2018. Thanks, Chris, Joe, and Sean ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WGLC for draft-ietf-tls-dtls13
This is the working group last call for the "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please review the document and send your comments to the list by 2359 UTC on 30 November 2018. Thanks, Chris, Joe, and Sean ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WGLC for draft-ietf-tls-dtls-connection-id
This is the working group last call for the "Connection Identifiers for DTLS 1.2" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/. Please review the document and send your comments to the list by 2359 UTC on 30 November 2018. Thanks, Chris, Joe, and Sean ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WG adoption call: draft-wood-tls-ticketrequests
At TLS@IETF103, there was consensus in the room to adopt draft-wood-tls-ticketrequests. This message is to confirm that consensus. If you do not support adoption of draft-wood-tls-ticketrequests as WG item please say so by 2359UTC on 30 November 2018 (and say why). Thanks, Joe and Sean ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft minutes for TLS, Monday session
Thanks, Rich! On Mon, Nov 5, 2018 at 4:16 PM Salz, Rich wrote: > > Draft minutes attached; please post corrections to the list. > > > > > > ___ > 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
