Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3
I've been thinking about this on and off. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: 08 March 2018 23:25 I think that this and draft-putman are not competing, but rather that they serve different use cases Agreed. It sounds like you have a set of use cases where you know how to predistribute the server key? This is the part we found challenging in the web context. Yes, the use case I was addressing was identical to external PSK, so the server key is distributed in the same way as the external PSK is distributed (for example, factory provisioning). But in the web context, it occurs to me that the server key could be distributed in the URL. An method similar to (or even a repurposing of) the username/password option could be used when chaining from one web site to another. For example, one site could link to another using the URL https://:@. This would allow the client to make its first request to the new site using 0-RTT traffic. A number of issues: 1) What if the public key has been retired? The client should include alternative authentication methods so that the handshake could proceed, though of course the request would have to be repeated once the connection was established. 2) This allows an attacker to leverage a vulnerability in one site to impersonate another. To mitigate this, the handshake could include Certificate/CertificateVerify messages in server's response to provide independent authentication. 3) Does this work at web scale? I can't answer: not my area of expertise. Proxies would have to be smarter, but provided the client includes non-3DH authentication methods in the ClientHello, then the failure cases will not cause any additional RTTs in setting up the connection. Is it worth tackling these issues to save one RTT when connecting to a new host? Again, I don't know, but I think it's a question worth asking. Tony Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK. This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
I support separation of concerns: publish as is, and start new work to extend existing Strict Transport Security mechanisms to include DANE authenticated TLS. Currently the draft is describing only a single mechanism: Letting owners of a (DNSSEC signed) domain vouch for their own TLS services. Not needing a third party for this is IMHO already valuable. HTTP Strict Transport Security (HSTS) [RFC6797] is extensible with directives. A new document could provide a useDANE directive for HSTS. That document could furthermore make more explicit, that when the chain extension delivers a denial of existence proof or a proof of insecurity, that a fallback to non-DANE PKIX has to be done. The chain extension already contains verification of Denial Of Existence proofs, because that is needed for verifying wildcard expansions. It does not explicitly mention the fallback to non-PKIX with a Denial of Existence proof or insecurity proof for the TLSA record, because it is (currently) irrelevant when the extension could simply be left out too. However, it does implicitly by referring to the DANE RFCs in paragraph 2 of section 6. Verification: > If the authentication chain is correctly verified, the client then > performs DANE authentication of the server according to the DANE TLS > protocol [RFC6698] [RFC7671]. Because the current draft is describing only the embedding of DANE records to authenticate the TLS service, it is quite short and to the point. I am afraid that built-in STS would bloat it with a lot of concerns that are not specific for the simple mechanism of embedding DANE. The extension as currently is does not add security like DANE over DNS protocol would have. This is pointed out in in the draft in Section 8, in which a mechanism like STS is also already suggested. I have a few questions too. Currently the extension contains only DNSSEC data, which can be verified to be authentic and correct. Is this also true for an additional TTL value? Is it safe to do STS at TLS ClientHello time? Why is there not a STS specification at TLS level already (which would also cover imaps, pops etc.), but only for protocols one layer above TLS? -- Willem Op 04-04-18 om 19:50 schreef Joseph Salowey: > Hi Folks, > > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the > working group is either to publish the document as is or to bring the > document back into the working group to address the following issues: > > - Recommendation of adding denial of existence proofs in the chain > provided by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document. Please > answer the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? > > If the answer to 1) is no then please indicate if you think the working > group should work on the document to include > > 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 > > This call will be open until April 18, 2018. > > Thanks, > > Joe > > > > > ___ > 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 Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey wrote: > Hi Folks, > > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the > working group is either to publish the document as is or to bring the > document back into the working group to address the following issues: > > - Recommendation of adding denial of existence proofs in the chain > provided by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document. Please answer > the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? > Yes. I support the publication of the document as is. and would like to explain my position a bit. I'm very sympathetic to Viktor's desire to enhance this protocol to provide downgrade resistance against PKIX attacks, and I generally would share that desire too. But I would also like to publish a document that has the solid consensus of the community that is one of key potential target consumers of this draft (web browsers and servers). So I'm giving more weight to their views and preferences. To date, the only people from that community that have spoken up have expressed strong opposition to Viktor's proposed enhancement. I also feel that the amount of time it has taken to finish up this draft has significantly hurt its deployment chances. In the early days of this draft there was (in my view) a window of opportunity where some browsers had actual interest in implementing this spec. But in the intervening time, there have been enough bandaids (CT and strengthed CAB forum requirements) applied to the WebPKI that to many people in the web community, the risk of bad actors has been sufficiently mitigated. But to the extent that there are still some folks interested in this proposal, I see no benefit in proposing an additional feature that they've stated doesn't work for them, or that they will not use. Another important facet of this debate that so far has not surfaced on recent mailing list discussions is an assessment of the relative benefits of webpki versus dane, and the recognition that there are strongly divergent views on this topic. In the early days of this draft, a number of web folks made it quite clear to me that this protocol can't be used to compel the use of DANE, and that the browser gets to decide what to use (and so dane-to-pkix downgrade attacks were not a concern for them). The large majority of DNSSEC proponents I know (and I'll state upfront that I'm one of them) clearly feel that DANE is superior to webpki, and that it's logical that DANE should be used to address webpki security issues. But this view is not shared by many others, most particularly in the web community. I've been involved in many lengthy debates on this topic, and the arguments against DANE usually boil down to: (1) widespread use 1024-bit RSA as the weak link in the majority of DNSSEC chains, (2) mistrust of registrars and their potential security failings, (3) mistrust of registries and/or other ancestor zones that could mount targeted attacks that could only be detected by a DNSSEC key transparency system, ala CT. These are legitimate arguments, and until we have better answers to them, I'm not inclined to aggressively push DANE, and position it as unconditionally superior, on communities that have expressed these concerns. Viktor has asserted that no-one will be motivated to deploy DANE without protection against PKIX downgrade, because there is no compelling enough additional gain of security. He may be right or wrong, but I've already heard several web folks disagree with him. And furthermore, they've expressed what I think are legitimate concerns about the fragility of the pinning proposal. Yes, I agree that it's not as bad as HPKP, but I also agree that there are more risks and failure possibilities than HSTS. As for other applications, we've already heard from a number of folks in the DNS over TLS camp that the draft works for them in the current form. Most DNS over TLS clients are expected to have explicit configuration of their resolver addresses and DANE capabilities. Some possible ways forward I see for folks wanting to develop a version of this spec with PKIX downgrade resistant capabilities (I've already stated earlier, that I would be happy to participate in such efforts): * Develop a new spec, with a new codepoint, and let the specs compete for adoption. * Develop a -bis document - if we manage to get WG consensus on the approach at a later date. * Do something outside the protocol, and specific to applications that want to include mechanisms to mandate DANE usage (like a HTTP header). -- Shumon Huque ___ 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 10, 2018, at 9:48 AM, Shumon Huque wrote: > > But I would also like to publish a document that has the solid > consensus of the community that is one of key potential target > consumers of this draft (web browsers and servers). So I'm giving > more weight to their views and preferences. To date, the only > people from that community that have spoken up have expressed > strong opposition to Viktor's proposed enhancement. There'll be negligible adoption of this draft as-is by Web Server operators on the public Internet. It offers them all pain and no gain. ZERO additional security over and above what they get with Let's Encrypt, only additional operational complexity and a new way to fail when the client supports DANE and the TLSA records are stale. Outside a few bilateral or intramural arrangements for mandatory DANE by clients when accessing specific destination servers, anyone deploying the present specification for the Web, is a masochist, or simply ignorant of what they're getting. What your response omits is any sort of cost/benefit analysis of the applicability of the present proposal to the Web. To be a proponent of adoption, you need to propose a specification that delivers tangible benefits at [plausibly] acceptable cost. No amount of wishful thinking or expedited publication will lead to meaningful adoption of a technology that is all cost and no benefit. If there's a flaw in my cost/benefit analysis posted earlier in this thread, please post a correction. From: Martin Thomson Date: Thu, 5 Apr 2018 12:07:57 +1000 To: TLS WG Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension [skepticism re pinning, addressed in follow-ups] Your cost benefit analysis seems about right though. To Willem's point, moving the TTL negotiation out of the TLS extension into HTTP STS metadata means that each application protocol (IMAP, JMAP, POP, SMTP submission, ...) that would employ this specification to address the "last mile" problems with DNSSEC at mobile client systems, would need to be extended with a similar protocol extension. That's rather a lot of duplicate work (and a lot more delay) for something that can be done just once and promptly in this specification. -- 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 Tue, 10 Apr 2018, Willem Toorop wrote: I just want to clarify one misconception in Willem's statement. See my previous emails to thist list for my full arguments on this issue. The chain extension already contains verification of Denial Of Existence proofs, because that is needed for verifying wildcard expansions. This might confuse people. I am talking about denial of existence of any TLSA record. You are talking about proof of non-existance of other TLSA records besides the one you are returning. These are completely different issues. I just want to ensure people realise when I said we need proof of non-existence, that people do not read your line "already contains this" as me being wrong. It does not explicitly mention the fallback to non-PKIX with a Denial of Existence proof or insecurity proof for the TLSA record, because it is (currently) irrelevant when the extension could simply be left out too. So that's not one bug, but two bugs. Defining them out of scope is not what we should do. For instance, the document could already assume that the proof of TLS extension (pinning) is going to be solved elsewhere, and therefor a full denial of existence proof in this document would be valuable. The document does not specify what to do when it does not find a TLSA record to include. It does state: If the server is configured for DANE authentication, then it performs the appropriate DNS queries, builds the authentication chain, and returns it to the client. So if the server is configured for DANE, and it only finds denial of existence proofs of its own TLSA record, what is the expected behaviour? This hints at returning the proof of non-existence, but clearly even the authors are now saying they did not mean this and a server is not required to do this. Clearly the text needs clarification, and if it then leaves out denial of existence, it needs a justification for that as well. 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 Apr 10, 2018, at 11:22 AM, Paul Wouters wrote: > > This hints at returning the proof of non-existence, but clearly even the > authors are now saying they did not mean this and a server is not > required to do this. Clearly the text needs clarification, and if it > then leaves out denial of existence, it needs a justification for that > as well. Paul makes a good point. If indeed at some later time (as Willem suggests) a commitment to deliver the extension is made at some application layer, then the underlying TLS extension code will need to be able to return denial of existence of TLSA records when these are deleted or not yet present. And yet there is nothing in the document that describes returning denial of existence for the requested TLSA records, except to validate a wildcard TLSA RRset (which is still a positive response). So indeed the present document does not support responses that are a denial of existence *of the requested TLSA RRset*. So at the very least this defect will need to be addressed, (option (A)). This in no way weakens the imperative for (C) (both denial of existence support and an extension support TTL). -- 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
Hi Viktor, With no hats. On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote: > > > > On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote: > > > > But I would also like to publish a document that has the solid > > consensus of the community that is one of key potential target > > consumers of this draft (web browsers and servers). So I'm giving > > more weight to their views and preferences. To date, the only > > people from that community that have spoken up have expressed > > strong opposition to Viktor's proposed enhancement. > > There'll be negligible adoption of this draft as-is by Web Server > operators on the public Internet. It offers them all pain and no > gain. ZERO additional security over and above what they get with > Let's Encrypt, only additional operational complexity and a new > way to fail when the client supports DANE and the TLSA records > are stale. I'd like to expand the discussion a little bit, on the question of what the goals of this document are, as well as that they should be. Your text above seems to imply that you see the goal of the document as being a security mechanism to DANE-authenticate TLS connections. But it's not clear to me that this is the best reading of the current document text. Re-quoting some text you had included in the thread previously: [...] The intent of this proposal is to allow TLS clients to perform DANE Authentication [RFC6698] [RFC7671] of a TLS server without performing additional DNS record lookups and incurring the associated latency penalty. It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records because of an interfering or broken middlebox on the path between the client and a DNS server [HAMPERING]. And lastly, it allows a TLS client to validate the server's DANE (TLSA) records itself without needing access to a validating DNS resolver to which it has a secure connection. This mechanism is useful for TLS applications that need to address the problems described above, typically web browsers or SIP/VoIP [RFC3261] and XMPP [RFC7590]. [...] I'd like to see if we can agree on what "the problems described above" are. I am reading the quoted text to say that the problems are: 1) needing to incur additional latency by doing DNS lookups 2) interfering/broken middleboxes that drop DANE records 3) needing a secure connection to a validating resolver While it is true that performing DANE Authentication generally does have a security role, the three items I list above are essentially matters of convenience, and not themselves relevant for security. In this sense, the immediate goal of the document is more to play a role as a transport than to provide security directly. I concede that it remains useful to consider what the client will do with the received DANE records or denial thereof, so as to not unduly block off future routes for development. But it seems at least possible to take a very broad view in this space, including even the possibility of additional TLS extensions that can modify the behavior of this one (such as a modification to provide pinning-like behavior). Such extensions could be introduced closer in time to when the desire to implement and use such behavior appears. So, can we ask ourselves what we intend to get from the document? I suspect that the vehemence of disagreement being presented stems from a disagreement in the goals we are seeking to achieve. -Ben ___ 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 Tue, Apr 10, 2018 at 12:48 PM, Benjamin Kaduk wrote: [...] > I concede that it remains useful to consider what the client will do > with the received DANE records or denial thereof, so as to not unduly > block off future routes for development. But it seems at least possible > to take > a very broad view in this space, including even the possibility of > additional > TLS extensions that can modify the behavior of this one (such as a > modification > to provide pinning-like behavior). Maybe that's the best option. Advance the current document as-is. And also develop a separate DANE pinning extension (now'ish ..) -- Shumon Huque ___ 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 Tue, Apr 10, 2018 at 01:25:02PM -0400, Shumon Huque wrote: > On Tue, Apr 10, 2018 at 12:48 PM, Benjamin Kaduk wrote: > [...] > > > I concede that it remains useful to consider what the client will do > > with the received DANE records or denial thereof, so as to not unduly > > block off future routes for development. But it seems at least possible > > to take > > a very broad view in this space, including even the possibility of > > additional > > TLS extensions that can modify the behavior of this one (such as a > > modification > > to provide pinning-like behavior). > > > Maybe that's the best option. Advance the current document as-is. And also > develop a separate DANE pinning extension (now'ish ..) Perhaps, but we should come to agreement on the actual goals before we get too far... -Ben ___ 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 Tue, Apr 10, 2018 at 11:22 AM, Paul Wouters wrote: > On Tue, 10 Apr 2018, Willem Toorop wrote: > > I just want to clarify one misconception in Willem's statement. See my > previous emails to thist list for my full arguments on this issue. > > The chain extension already contains verification of Denial Of Existence >> proofs, because that is needed for verifying wildcard expansions. >> > > This might confuse people. I am talking about denial of existence of any > TLSA record. You are talking about proof of non-existance of other TLSA > records besides the one you are returning. These are completely > different issues. I just want to ensure people realise when I said we > need proof of non-existence, that people do not read your line "already > contains this" as me being wrong. > > > It does not explicitly mention the fallback to non-PKIX with a Denial of >> Existence proof or insecurity proof for the TLSA record, because it is >> (currently) irrelevant when the extension could simply be left out too. >> > > So that's not one bug, but two bugs. Defining them out of scope is not > what we should do. For instance, the document could already assume that > the proof of TLS extension (pinning) is going to be solved elsewhere, > and therefor a full denial of existence proof in this document would be > valuable. > > The document does not specify what to do when it does not find a TLSA > record to include. It does state: > > If the server is configured for DANE >authentication, then it performs the appropriate DNS queries, builds >the authentication chain, and returns it to the client. > > So if the server is configured for DANE, and it only finds denial of > existence proofs of its own TLSA record, what is the expected behaviour? > > This hints at returning the proof of non-existence, but clearly even the > authors are now saying they did not mean this and a server is not > required to do this. Clearly the text needs clarification, and if it > then leaves out denial of existence, it needs a justification for that > as well. Personally, I would be okay with relaxing/clarifying the language in the draft a bit so that it does not rule out the possibility that a DNSSEC (NSEC/NSEC3) chain corresponding to an NXDOMAIN or NODATA response can be returned. I wonder if that, together with a new extension that can convey DANE pinning information is a way forward .. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
[I only have part of the thread available, and so am replying to the last message I see.] I agree that the draft MUST explicitly support chains corresponding to a NXDOMAIN or NODATA responses to have sufficient value. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 ___ 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 Tue, Apr 10, 2018 at 09:48:24AM -0400, Shumon Huque wrote: > Yes. I support the publication of the document as is. > > and would like to explain my position a bit. > > I'm very sympathetic to Viktor's desire to enhance this protocol > to provide downgrade resistance against PKIX attacks, and I > generally would share that desire too. > > But I would also like to publish a document that has the solid > consensus of the community that is one of key potential target > [...] Assertion of facts not in evidence. We're here because there is a question as to consensus (and/or process). We need to address that. The earlier consensus is not just applicable, as if it were, we would not be having this LC. Using the earlier consensus as justification is not responsive to the substantive issues, and is just not a good argument. A valid argument would be that this extension works for DPRIV, but you should consider that even for DPRIV there is a downgrade unless the client knows a priori that the server does (or does not) support this extension. > I also feel that the amount of time it has taken to finish up > this draft has significantly hurt its deployment chances. In the I'll be blunt: I do not care about how long it's taken and neither should anyone else (besides, it will take longer on the RFC-Editor queue anyways; as an RFC author myself, I know this all too well). I care about the quality of the end result, and so should you, and so should the WG, IETF, and IESG. There is bug in the spec. The bug affects DPRIV as well as other applications -- it affects any application where the client does not know a priori whether the server will or will not be using this extension. > early days of this draft there was (in my view) a window of opportunity > where some browsers had actual interest in implementing this spec. See the point that even DPRIV is affected. You might argue that your DPRIV clients will know a priori whether the server supports this extension, but that would have to be true of all DPRIV clients. > But in the intervening time, there have been enough bandaids (CT > and strengthed CAB forum requirements) applied to the WebPKI that > to many people in the web community, the risk of bad actors has been > sufficiently mitigated. But to the extent that there are still some > folks interested in this proposal, I see no benefit in proposing an > additional feature that they've stated doesn't work for them, or > that they will not use. Contradition. Then why bother with DANE and this extension? Your argument is to cancel the Internet-Draft, not to publish it as-is, yet you are also arguing to publish as-is. Pick one. > Another important facet of this debate that so far has not surfaced > on recent mailing list discussions is an assessment of the relative > benefits of webpki versus dane, and the recognition that there are > strongly divergent views on this topic. [...] This is not the subject matter of this LC. > Viktor has asserted that no-one will be motivated to deploy DANE > without protection against PKIX downgrade, because there is no > compelling enough additional gain of security. He may be right or > wrong, but I've already heard several web folks disagree with him. > [...] You're not addressing the glaring downgrade attack. > As for other applications, we've already heard from a number of > folks in the DNS over TLS camp that the draft works for them in > the current form. Most DNS over TLS clients are expected to have > explicit configuration of their resolver addresses and DANE > capabilities. "Most" != "all". To live with the downgrade you'd have to make that "all". You might want to think about all the deployment scenarios ruled out by having this bug. > Some possible ways forward I see for folks wanting to develop a version > of this spec with PKIX downgrade resistant capabilities (I've already > stated earlier, that I would be happy to participate in such efforts): > > * Develop a new spec, with a new codepoint, and let the specs compete > for adoption. > * Develop a -bis document - if we manage to get WG consensus on the > approach at a later date. > * Do something outside the protocol, and specific to applications > that want to include mechanisms to mandate DANE usage (like a HTTP > header). Needless to say, I oppose your proposal for reasons I've stated before. Two specs is not better than one, and we can count on implementors missing one. 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 4/10/18 3:53 PM, Nico Williams wrote: > The earlier consensus is not just applicable, as if it were, we would > not be having this LC. I have no idea what that even means, to be honest. We're through last call, and it's not that the earlier wg consensus isn't "applicable," it's that you've raised new issues. So let's be clear about that. I've been watching this discussion and trying to get a handle on what's been going on (and how this fits into several other IETF issues more generally), and I think this discussion would be over if the people arguing in favor of changing the use of the extension had plans to implement it. But so far nobody has said that they do. It's been suggested that if we intend to stick with the original, intended use we can just ignore the extra bytes, which strikes me as an exceedingly odd argument for including new protocol features. It's unfortunate that over in DNS-land they're discussing how to get rid of unused features that increase complexity, while over here we're having a discussion of how to add unused features that increase complexity. I think those of us who care about the institutional effectiveness of the IETF and the value of the standardization process care quite a bit about the amount of time it takes to push a document through to publication. Aside from negatively affecting the chances of the success of a given protocol, it's harmful to the standards process more broadly and discourages participation from people who want to get work done. There's an unfortunate number of IETF protocols that people worked on for years and that never saw implementation, and it seems to me that we ought to be trying to minimize the chances of that happening with the protocols we're working on. I haven't seen anything in this discussion that leads me to believe that the extension as specified is fundamentally broken or insecure for its intended use. I'm good with adding clarifying text or scoping it more clearly, but beating this thing to death for a use case that nobody intends to implement seems a bit misguided to me. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F signature.asc Description: OpenPGP digital signature ___ 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 Tue, Apr 10, 2018 at 11:48:58AM -0500, Benjamin Kaduk wrote: > On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote: > > > On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote: > > > But I would also like to publish a document that has the solid > > > consensus of the community that is one of key potential target > > > consumers of this draft (web browsers and servers). So I'm giving > > > more weight to their views and preferences. To date, the only > > > people from that community that have spoken up have expressed > > > strong opposition to Viktor's proposed enhancement. > > > > There'll be negligible adoption of this draft as-is by Web Server > > operators on the public Internet. It offers them all pain and no > > gain. ZERO additional security over and above what they get with > > Let's Encrypt, only additional operational complexity and a new > > way to fail when the client supports DANE and the TLSA records > > are stale. > > I'd like to expand the discussion a little bit, on the question of > what the goals of this document are, as well as that they should be. I don't think that's necessary for settling this LC, but let's follow this for now: > Your text above seems to imply that you see the goal of the document > as being a security mechanism to DANE-authenticate TLS connections. Without precluding DANE + WebPKI. > But it's not clear to me that this is the best reading of the current > document text. Re-quoting some text you had included in the thread > previously: > >[...] The intent of this >proposal is to allow TLS clients to perform DANE Authentication >[RFC6698] [RFC7671] of a TLS server without performing additional DNS >record lookups and incurring the associated latency penalty. It also >provides the ability to avoid potential problems with TLS clients >being unable to look up DANE records because of an interfering or >broken middlebox on the path between the client and a DNS server >[HAMPERING]. And lastly, it allows a TLS client to validate the >server's DANE (TLSA) records itself without needing access to a >validating DNS resolver to which it has a secure connection. The last-mile problem described in the last sentence in the above quote is the most important point. This extension is not merely an optimization so that the client need not perform those additional DNS queries: it is a workaround to the last-mile problem. Moreover, this isn't just a run-time optimization, but also a developer optimization. Lastly, sometimes run-time and/or developer optimizations are actually necessary to get traction. >This mechanism is useful for TLS applications that need to address >the problems described above, typically web browsers or SIP/VoIP >[RFC3261] and XMPP [RFC7590]. [...] > > I'd like to see if we can agree on what "the problems described above" are. > I am reading the quoted text to say that the problems are: > > 1) needing to incur additional latency by doing DNS lookups > 2) interfering/broken middleboxes that drop DANE records > 3) needing a secure connection to a validating resolver (2) -> this extension is for clients to be able to use DANE when they otherwise could not. In order to be able to mix WebPKI and/or DANE, it is necessary to have the proofs of non-existence in order to be able to decide to dispense with DANE. Therefore this isn't just an optimization for when you want to use DANE: it is for when you are willing to use DANE, and willing to not do DANE, but you need to know which to do. It is because the choice is WebPKI and/or DANE that the downgrade attack, and the pinning mitigation (with TOFU semantics) matter. For example, on the web, in IMAP, ..., the WebPKI *and* (not *or*) DANE usage (DANE usages PKIX-TA #0 and PKIX-EE #1) are likely to matter. > While it is true that performing DANE Authentication generally does have > a security role, the three items I list above are essentially matters of > convenience, and not themselves relevant for security. In this sense, the > immediate goal of the document is more to play a role as a transport than to > provide security directly. I don't follow. The security role for DANE here is the whole story, and it is essential. How can we say that this is just about latency or last-mile problems when what DANE is doing at the end of the day is... provide authentication (security). > I concede that it remains useful to consider what the client will do > with the received DANE records or denial thereof, so as to not unduly > block off future routes for development. But it seems at least > possible to take a very broad view in this space, including even the > possibility of additional TLS extensions that can modify the behavior > of this one (such as a modification to provide pinning-like behavior). > Such extensions could be introduced closer in time to when the desire > to implement and use such behavior appears. Again, my concern is that the fo
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Tue, Apr 10, 2018 at 04:17:14PM -0800, Melinda Shore wrote: > On 4/10/18 3:53 PM, Nico Williams wrote: > > The earlier consensus is not just applicable, as if it were, we would > > not be having this LC. > > I have no idea what that even means, to be honest. We're through > last call, and it's not that the earlier wg consensus isn't > "applicable," it's that you've raised new issues. So let's be > clear about that. It means that because we are having this LC, we cannot use the previous consensus as evidence for ending this LC with a "no". We might as well never have had the LC in that case, and it is not a substantive response to the LC anyways. It's a "please go away" response. > I've been watching this discussion and trying to get a handle > on what's been going on (and how this fits into several other > IETF issues more generally), and I think this discussion would > be over if the people arguing in favor of changing the use > of the extension had plans to implement it. But so far nobody [...] Viktor began implementing DANE 8 months after it was published. That spec was ready. This spec is not. > It's unfortunate that over in DNS-land they're discussing how > to get rid of unused features that increase complexity, while over > here we're having a discussion of how to add unused features that > increase complexity. Sure, this is true, but it doesn't mean that we should exclude features that are necessary to making the protocol work in the first place. This is a TLS extension for stapled DANE, not a DPRIV extension to TLS. > I think those of us who care about the institutional effectiveness > of the IETF and the value of the standardization process care > quite a bit about the amount of time it takes to push a document > through to publication. Aside from negatively affecting the chances > [...] What is it to "care about the institutional effectiveness of the IETF "? Is it to care only about speediness? Or only about correctness? How about a bit of both? Honestly, if all you want is speediness, why not go to OASIS? Register the extension codepoint with IANA and publish elsewhere, why not? Doing things in the IETF means... the peanut gallery are not just spectators. Bringing work to the IETF means incurring the risk that others may glom onto it. It happens *all the time*, it's happened to me, and it will happen to others. There is nothing special to this piece of work that should exempt 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 10, 2018, at 8:17 PM, Melinda Shore > wrote: > > There's an unfortunate number of IETF protocols that > people worked on for years and that never saw implementation, and > it seems to me that we ought to be trying to minimize the chances > of that happening with the protocols we're working on. Exactly, which is why we need to make sure that the protocol does not fail to address its natural use-cases. This is a protocol for stapled DANE in TLS, and many potential applications will run in mixed WebPKI + DANE environments and will need to be able to do DANE *when possible*, in a downgrade-resistant manner (in this case after first contact). > I haven't seen > anything in this discussion that leads me to believe that the > extension as specified is fundamentally broken or insecure for its > intended use. The intended use in the introduction does not preclude Web browser HTTPS, JMAP, IMAP, POP, NNTP, SMTP Submission, XMPP, ... with only statically configured DANE for DPRIV in scope. DPRIV may well be the application that's ready now, but closing the door on others is surely unwise. > I'm good with adding clarifying text or scoping it > more clearly, but beating this thing to death for a use case that > nobody intends to implement seems a bit misguided to me. It is a mistake to confuse lack of immediate adoption plans with evidence that no such implementations will ever happen, and should be precluded at the outset. I had no idea DANE existed (too busy implementing comprehensive TLS support in Postfix to follow IETF work) when the DANE WG concluded work on RFC6698. 8 months later Tony Finch brought DANE to my attention, and I began implementation at that time. My implementation was the first non-toy implementation of DANE that got used in real systems. Was I ready to implement in August of 2012? No. Did I then never implement? Of course not, indeed we'd not be talking about DANE at all (it would be dead) if it were not for that work, and subsequent work to eliminate hurdles in the form of buggy authoritative servers at some major providers, integration into OpenSSL, Exim, ... The arguments against the proposal continue to ignore the technical issues and focus on perceived delay. If you really want to avoid delay, let's adopt the changes, and we'll be done. If there are technical flaws in the cost/benefit analysis that motivates the changes, please address those in detail. I see nothing in the draft that justifies limiting its scope to just a narrow application profile in which DANE is statically mandated by client policy. That limitation fails to scale. Even with DPRIV it should be possible for a server that no longer has TLSA records to provide a denial of existence proof (thus at least option (A) from the consensus call message) and employ PKIX instead (a domain may become unsigned if they change their mind about implementing DNSSEC). Option (B) supports incremental adoption, and provides downgrade protection after first contact, dramatically increasing the applicability. The changes are small, but needed to not preclude further implementation work in new application areas. There may not be implementors right away, but we should leave the door open for when they are. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] A new argument (Re: Consensus Call on draft-ietf-tls-dnssec-chain-extension)
Let me synthesize one new argument, though I've implied it before, but I think making it explicit may be useful: The cost of making the requested changes is fixed and can be estimated -- measured even, after the fact. I argue that cost is low. But the cost/risk of not making the requested changes is intangible -- could be very high, or barely more (but not less) than the cost of making the changes. We'd have to be sanguine to dismiss my estimate of the cost/risk of fixing this later. Perhaps that's right anyways, but it can plausibly be very large too, and that surely should trump a small fixed cost, therefore we're better off taking this hit now. I might clarify other points on the main thread, but, really, for me, the whole thing boils down to: are we looking out for the future, and is our contention of risk to future DANE deployment even plausible. It won't surprise anyone that I believe my estimate of the risk to future DANE deployment is not merely plausible. It won't surprise anyone either that I believe that even if the likelihood of reduction of future DANE deployment were low, we, the IETF, and in particular the IESG, ought to care about making our protocols sufficiently generic when the cost of doing so is low, as surely it would be here. We've already incurred what should be much of the cost of making the requested changes. A wee bit little more won't hurt. Let us now then proceed to proposed text. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
