[TLS] Draft updates: tls-dnssec-chain
> On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey wrote: > Concerns have been raised about the trade-offs associated with pinning and I do not think we currently have consensus to add pinning. While I think it may be possible to come to consensus on pinning I think it may take some time. I believe we can quickly get consensus for the following approach: > > 1. Scope the document to the assertive use cases > 2. Explicitly allow (but do not require) DoE be included > 3. Remove current text about pinning > 4. Re-submit the document for publication and start work on a separate extension that supports pinning Hi Joe, Here is the proposed text for items 1, 2, and 3. It's also in the tls-wg github repo. We'll probably tweak and wordsmith some more, but this is the gist of it. > 1. Scope the document to the assertive use cases * Added scope description to Intro: This specification can also be used to optionally convey authenticated denial of existence of TLSA records. Restrictive uses that might require such proofs (such as the PKIX constraining modes of DANE, or where DANE should always be preferred over other modes of authentication such as traditional PKIX) are thus not in its intended scope. Such restrictive uses can however be supported opportunistically. > 2. Explicitly allow (but do not require) DoE be included (Note: I've noticed Viktor has submitted some expanded text describing denial of existence. We'll review and likely incorporate much of that) * New section: 3.4.1, that permits but doesn't require authenticated denial: 3.4.1. Support for Authenticated Denial of Existence TLS servers that do not have a signed TLSA record MAY instead return a DNSSEC chain that provides authenticated denial of existence. This specification does not require TLS servers to provide such a denial of existence chain, otherwise it could not be deployed incrementally in environments where not all TLS servers support this extension. Authenticated denial chains include NSEC or NSEC3 records that demonstrate one of the following facts: o The TLSA record does not exist. o There is no signed delegation to a DNS zone which is either an ancestor of, or the same as, the TLSA record name. * Text in Section 8 (Mandating) that rewrites language that in the previous draft stated that it doesn't support denial of existence: This protocol allows TLS servers to prove that they don't have a signed TLSA record by returning a denial of existence chain. However, as explained in Section 3.4.1, it does not require TLS servers to do so. In the absence of such a proof, a TLS client misdirected to a server that has fraudulently acquired a public CA issued certificate for the real server's name, could be induced to establish a PKIX verified connection to the rogue server that precluded DANE authentication. Application ecosystems where all TLS servers are expected to implement this extension could require such authenticated denial proofs to be delivered by TLS servers that don't have signed TLSA records. > 3. Remove current text about pinning * Remove client initiated pinning para from Section 8: This paragraph was entirely deleted: If TLS applications want to mandate the use of this extension for specific servers, clients could maintain a whitelist of sites where the use of this extension is forced. The client would refuse to authenticate such servers if they failed to deliver this extension. Client applications could also employ a Trust on First Use (TOFU) like strategy, whereby they would record the fact that a server offered the extension and use that knowledge to require it for subsequent connections. Thanks, -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
On Fri, Apr 27, 2018 at 4:17 PM, Viktor Dukhovni wrote: > > It would be helpful to know where opponents stand on negotiating > continued use of the extension in general and in the future. We > are confused by their statements so far, and wonder if they are > not just generally in opposition to any negotiation of continued > support for the extension (in all applications), and whether that > might be driving their opposition to the 16 bits, whether consciously > or not. > Hi Viktor, I am in support of doing the pinning in a new extension, and will even help you write the draft if you like. I'm pretty sure we could have easily done this in the time that has been taken up on list endlessly and repetitively discussing this. Clearly I can speak only for myself, but I strongly suspect others in the WG will also support this (as long as it's in a separate extension), so if you pursue this approach, I think you'll succeed in adding this functionality, and will not be actively blocked by others. As far as I can assess, the reason you are getting resistance for adding a pinning field in this spec is two fold: First, there is no agreement that your reason for doing pinning, i.e. that DANE needs downgrade resistance against PKIX attacks is even valid. This can be clearly seen from various comments on list and at IETF/London, such as the point made many times that the original purpose of this draft was to add DANE as an additional possible authentication mechanism in TLS, not to position it as a mechanism that if available unconditionally trumps PKIX authentication. If you look back at my back-and-forth answering IESG review comments, you will observe that I had to add text to the draft that says TLS clients can fail back to normal PKIX authentication if DANE fails for any reason (i.e. a protocol behavior that is the opposite of downgrade resistance). There are other comments like (paraphrasing) "What's the downgrade problem? The only security downgrade issue I see is DNSSEC's use of legacy crypto"? Clearly, for most DANE proponents, an obvious goal for the protocol would be to protect against PKIX attacks. In an ideal world, I share that view also. But I also recognize the other views I just described, and am willing to make compromises to get a foot in the door for DANE first. There will always be opportunities to improve the protocol later. In fact, the legacy crypto issue will always be a huge impediment for any DANE proponent in arguing against the Internet PKI. An argument I've heard many times: Since most of the Internet PKI has moved to 2048-bit RSA or better, why would I degrade the security of my system by moving to DANE, which in most cases is protected by 1024-bit RSA ZSK's in the weakest part of the chain (some chains are even weaker)? And if so, why should PKIX not need downgrade resistance against DANE, rather than vice versa? For DANE proponents to make a stronger case, they need to urgently solve this problem. I'm not sure how to do that quickly - it probably involves getting ICANN to impose rules on TLDs prohibiting weak keys (which would likely take years). The second reason is that pinning really is a controversial feature. And for this reason, putting it in the core spec will be difficult. I won't repeat all the arguments and concerns expressed already, many of which I share by the way. So moving this feature into a new optional extension (both the pinning field and a description of the associated behavior) appears to me to be the past of least resistance. By continuing to argue your position, the most you can hope to achieve is deadlock. Shumon. (Addendum: I did want to thank you for pushing on the issue of explicitly allowing authenticated denial of existence chains in the current draft. In environments where all TLS servers support this extension, this allows the protocol to be bulletproof in a way that satisfies even the security purist, so I'm glad it's in the core spec.). -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
> On Apr 28, 2018, at 12:26 PM, Shumon Huque wrote: > > I am in support of doing the pinning in a new extension, and will > even help you write the draft if you like. I'm pretty sure we could > have easily done this in the time that has been taken up on list > endlessly and repetitively discussing this. I should note that substantial issues were discovered (and will be addressed) during the consensus call, which ended Apr 18th, and that there is not yet a revised version of the draft that addresses these, so while the discussion back and forth has been lengthy, it has gone on in parallel with process that needed to take place and is ongoing. So discussion of doing more than removing the unilateral pinning that was present and adding denial of existence which was needed has not as yet caused any additional delay. > Clearly I can speak only for myself, but I strongly suspect others > in the WG will also support this (as long as it's in a separate > extension), so if you pursue this approach, I think you'll succeed > in adding this functionality, and will not be actively blocked by > others. We may yet have to see how much support or opposition the follow-on document will meet. What continues to be puzzling is resistance to adding a field that imposes negligible burden on the present spec, and would clearly be included in the follow-on extension. It might well be the only thing that's in the follow-on extension, and so provisioning space for it has a strong chance of simplifying the burden on future implementations that would need only implement code for just one extension structure instead of two. Worst-case we have two reserved bytes in the current extension. > As far as I can assess, the reason you are getting resistance for > adding a pinning field in this spec is two fold: > > First, there is no agreement that your reason for doing pinning, > i.e. that DANE needs downgrade resistance against PKIX attacks > is even valid. The reasons are an easy exercise in logic if one is to be able to deploy DANE at all, incrementally in *any* existing WebPKI application (say IMAP). This was addressed weeks back when I explained that without downgrade protection the deployment of this extension is all cost and no benefit. There was agreement on this point even from those who opposed adding the downgrade protection. > This can be clearly seen from various comments on > list and at IETF/London, such as the point made many times that > the original purpose of this draft was to add DANE as an additional > possible authentication mechanism in TLS, not to position it as a > mechanism that if available unconditionally trumps PKIX authentication.. Those comments are gut reactions that have not considered the issue with care. We must discount them. This extension can only work as a mandatory sole mechanism. All other models fail the cost/benefit analysis. Some may want to deny others the opportunity to use this extension in additional contexts. My reaction to that is that they are under no obligation do use it themselves, and setting the field to zero opts them out of such use. Nothing I'm proposing mandates downgrade protection for the extension. I am just asking for it to be possible, on a mutual opt-in basis between client and server. > If you look back at my back-and-forth answering IESG review comments, > you will observe that I had to add text to the draft that says TLS clients > can fail back to normal PKIX authentication if DANE fails for any reason > (i.e. a protocol behavior that is the opposite of downgrade resistance). Clients can choose to do that whether or not the downgrade protection is available, and servers can opt-out of downgrade protection. What we are talking about is whether downgrade protection is to be unavailable even if both sides wanted it, and the application supported it. I have no intention of forcing anyone to enable downgrade protection in code they develop and support or systems and applications they deploy. Their choice to leave it off. My problem is with the IETF leaving a gap in the specification that removes the option of downgrade protection. > There are other comments like (paraphrasing) "What's the downgrade > problem? The only security downgrade issue I see is DNSSEC's use of > legacy crypto"? Folks who don't trust DNSSEC are unlikely to deploy the extension, but if they do, will presumably want PKIX-EE(1) or PKIX-TA(0) so that WebPKI is also employed. These however require downgrade protection. Without downgrade protection you're stuck sometimes trusting just DANE. If one considers DANE to be too weak the solution is to make it STRONGER not weaker!!! To make it stronger you need downgrade protection so that you can use PKIX-EE(1) and PKIX-TA(0) and ignore DANE-EE(3) and DANE-TA(2) as "unusable". > Clearly, for most DANE proponents, an obvious goal for the protocol > would be to protect against PKIX attacks. In an ideal world, I share > that v
Re: [TLS] Draft updates: tls-dnssec-chain
> On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote: > >This specification can also be used to optionally convey >authenticated denial of existence of TLSA records. Restrictive uses >that might require such proofs (such as the PKIX constraining modes >of DANE, or where DANE should always be preferred over other modes of >authentication such as traditional PKIX) are thus not in its intended >scope. Such restrictive uses can however be supported >opportunistically. The last sentence makes no sense. The term "Restrictive uses" is poorly defined. The reduction in scope is effectively a reduction to just the cases where the extension is mandatory, if that's what you intend to do then say so (expect pushback). Please do not imply that any non-mandatory "additive" use-cases are viable. They are not. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft updates: tls-dnssec-chain
On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni wrote: > > > > On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote: > > > >This specification can also be used to optionally convey > >authenticated denial of existence of TLSA records. Restrictive uses > >that might require such proofs (such as the PKIX constraining modes > >of DANE, or where DANE should always be preferred over other modes of > >authentication such as traditional PKIX) are thus not in its intended > >scope. Such restrictive uses can however be supported > >opportunistically. > > The last sentence makes no sense. The term "Restrictive uses" is poorly > defined. The reduction in scope is effectively a reduction to just the > cases where the extension is mandatory, if that's what you intend to do > then say so (expect pushback). > > Please do not imply that any non-mandatory "additive" use-cases are > viable. They are not. > I agree with Viktor here. You could imagine enforcing a restriction you see in a DANE extension the cert you get milliseconds later, but that's pretty useless given that an attacker can just not send the extension. Let's just scope this to the additive case. > > -- > 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] Draft updates: tls-dnssec-chain
> On Apr 28, 2018, at 2:17 PM, Richard Barnes wrote: > > Let's just scope this to the additive case. When you say "additive case" do you mean to cover just applications where the extension is mandatory? Or you expect the extension to also have some value when it is optional? I thought I explained fairly well why optional use does not pan out, there was no cost/benefit to refute the one I posted (quoted below). Servers will never start deploying the non-mandatory 'additive case', absent downgrade protection, it makes no sense for them to do that: --- Viktor Dukhovni , 2018-04-08 19:27:36-0400 --- And yet, as it stands, the deployment cost-benefit analysis for this extension in existing applications plays out as follows: COSTS: * You still manage WebPKI certificates to support the majority of existing clients. * If the WebPKI is compromised, you're compromised. * If DNSSEC is compromised, you're compromised * You pay the complexity cost of also supporting the extension * You might present incorrect TLSA records and the connection might fail even when it would otherwise succeed with WebPKI BENEFITS: * Nothing other than bragging rights that you're cool enough to deploy a shiny new technology --- Notably, just a confirmation that the above is basically sound: --- Martin Thomson , 2018-04-05 12:07:57+1000 --- Your cost benefit analysis seems about right though. --- So with downgrade protection out, the present scope is *exactly* the applications where the extension is mandatory (whatever these might be). -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft updates: tls-dnssec-chain
On Sat, 28 Apr 2018, Shumon Huque wrote: TLS servers that do not have a signed TLSA record MAY instead return a DNSSEC chain that provides authenticated denial of existence. This specification does not require TLS servers to provide such a denial of existence chain, The second sentence is just repeating the MAY and is not needed. But more importantly, it does not specify what the extension content should be in the absense of a signed TLSA record and not wanting to put in the denial of existene. Are you expecting an empty payload? A single NULL payload? Or are you expecting the extension should be omitted entirely? And what is the expected client behaviour in that case? otherwise it could not be deployed incrementally in environments where not all TLS servers support this extension. It can be deployed incremendally as Viktor, Nico and I have shown repeatedly with a two byte value. Authenticated denial chains include NSEC or NSEC3 records that demonstrate one of the following facts: o The TLSA record does not exist. o There is no signed delegation to a DNS zone which is either an ancestor of, or the same as, the TLSA record name. "s/one of the following facts/either" In the absence of such a proof, a TLS client misdirected to a server that has fraudulently acquired a public CA issued certificate for the real server's name, could be induced to establish a PKIX verified connection to the rogue server that precluded DANE authentication. Application ecosystems where all TLS servers are expected to implement this extension could require such authenticated denial proofs to be delivered by TLS servers that don't have signed TLSA records. I think this belongs in the Security Section. It's a big security problem and so should be explained in the Security Section. > 3. Remove current text about pinning * Remove client initiated pinning para from Section 8: This paragraph was entirely deleted: If TLS applications want to mandate the use of this extension for specific servers, clients could maintain a whitelist of sites where the use of this extension is forced. The client would refuse to authenticate such servers if they failed to deliver this extension. Client applications could also employ a Trust on First Use (TOFU) like strategy, whereby they would record the fact that a server offered the extension and use that knowledge to require it for subsequent connections. And as stated before, removing this is not enough. You need to explain what the expected client behaviour is when the extension appears and disappears, either in this section, a seperate section, or the Security Section. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft updates: tls-dnssec-chain
> On Apr 28, 2018, at 2:34 PM, Paul Wouters wrote: > > But more importantly, it does not specify what the extension content > should be in the absense of a signed TLSA record and not wanting to > put in the denial of existene. Are you expecting an empty payload? > A single NULL payload? Or are you expecting the extension should be > omitted entirely? And what is the expected client behaviour in that case? The first commit in my pull-request provides a more complete description of DoE processing. https://github.com/tlswg/dnssec-chain-extension/pull/14/commits/859b164a5369e8c997713711771cfb3f7d87c90a#diff-bcaaf747fc40b8dd4fe4e10917b518f2L370 Don't know whether the authors have had a chance to take a look. The present text is IMHO still a bit too skimpy as you note: https://github.com/tlswg/dnssec-chain-extension/blob/master/draft-ietf-tls-dnssec-chain-extension-08.xml -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
On Sat, Apr 28, 2018 at 1:40 PM, Viktor Dukhovni wrote: > > > On Apr 28, 2018, at 12:26 PM, Shumon Huque wrote: > > > > So moving this feature into a new optional > > extension (both the pinning field and a description of the associated > > behavior) appears to me to be the past of least resistance. > > I wish I could be confident that such a specification would > be allowed to move forward. My fear is that the same visceral > opposition to DANE and DNSSEC would play out, and so I may as > well try to get past these now. > I would like to explore this. Is there anyone in the working group who would oppose such a new spec moving forward? (Maybe the WG chairs need to ask this question officially). Shumon ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
On Sat, 28 Apr 2018, Shumon Huque wrote: [ not going to repeat my technical arguments here, just going to comment on process ] First, there is no agreement that your reason for doing pinning, i.e. that DANE needs downgrade resistance against PKIX attacks is even valid. This is incorrect. From the replies to the consensus call on the list, it actually weights in favour of _some_ kind of downgrade resistance. In fact, it worries me that the consensus call outcome seems to come from non-public voices and not from a tally of those participants on the TLS list. This can be clearly seen from various comments on list and at IETF/London, such as the point made many times that the original purpose of this draft was to add DANE as an additional possible authentication mechanism in TLS, not to position it as a mechanism that if available unconditionally trumps PKIX authentication.. This is actually upsetting. I can assure you that since the late 90's, people were working on DNSSEC as an alternative for the webpki. I wrote RFC 7901 as a building block for doing so, and that RFC is now the basis of the format of the data in this document. It is an explicit goal of _some_ people at IETF and has been for decades. What the motivation is of the individual document editor is not relevant. Once the document was adopted by the WG it became a document that needs to represent WG consensus, not original author intent. I will agree to the point that people in the webpki sphere dislike DNSSEC and don't want to see it competing against webpki. But writing specifications to limit alternatives is not what the IETF is about. The two byte is too much argument is simply a strawman argument. The "additive use case" is a completely made up concept. No one in their right minds will want a security model of "DANE or WebPKI, whichever is weaker". If you look back at my back-and-forth answering IESG review comments, you will observe that I had to add text to the draft that says TLS clients can fail back to normal PKIX authentication if DANE fails for any reason (i.e. a protocol behavior that is the opposite of downgrade resistance). No one is objecting to that text. There are other comments like (paraphrasing) "What's the downgrade problem? The only security downgrade issue I see is DNSSEC's use of legacy crypto"? Everyone makes mistakes, even people in the IESG. Viktor, Nico and I have clearly explained the downgrade attack. If your argument is that the IESG said otherwise and we should believe them, then the IESG is wearing no clothes, unless the specific IESG individual will show us the technical argument of why there allegedly is no downgrade attack. Clearly, for most DANE proponents, an obvious goal for the protocol would be to protect against PKIX attacks. In an ideal world, I share that view also. But I also recognize the other views I just described, and am willing to make compromises to get a foot in the door for DANE first. There will always be opportunities to improve the protocol later. This is again not the proper argument to have. We make arguments based on technical merit and not based on "other [political] views". The technical points against a two byte zero value are non-existent. In fact, the legacy crypto issue will always be a huge impediment for any DANE proponent in arguing against the Internet PKI. An argument I've heard many times: Since most of the Internet PKI has moved to 2048-bit RSA or better, why would I degrade the security of my system by moving to DANE, which in most cases is protected by 1024-bit RSA ZSK's in the weakest part of the chain (some chains are even weaker)? And if so, At this rate, this RFC won't be ready before .com is using 2048bit ZSK's. The argument is pretty weak and ephemeral and should not be an argument when writing RFCs. why should PKIX not need downgrade resistance against DANE It already has that by simply not using DANE, which is what all current browsers already (sadly) do. The refusal of the two byte value however, does not reciprocate that freedom to those users who voluntarilly want to move away from webpki towards dane-only. vice versa? For DANE proponents to make a stronger case, they need to urgently solve this problem. I'm not sure how to do that quickly - it probably involves getting ICANN to impose rules on TLDs prohibiting weak keys (which would likely take years). Strawman. From what I know, Versign is already investigating the ZSK key length for its zones. Regardless of if that would take years or not, publishing new RFCs that for no reason prohibit moving towards this added security is not what the IETF should be doing. The second reason is that pinning really is a controversial feature. And for this reason, putting it in the core spec will be difficult. That is not a technical argument. And Viktor's proposal of just adding the two bytes set to a mandatory 0 in this specification moves the discussion of how/when to pin thi
Re: [TLS] Draft updates: tls-dnssec-chain
On Sat, Apr 28, 2018 at 2:17 PM, Richard Barnes wrote: > > > On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni > wrote: > >> >> >> > On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote: >> > >> >This specification can also be used to optionally convey >> >authenticated denial of existence of TLSA records. Restrictive uses >> >that might require such proofs (such as the PKIX constraining modes >> >of DANE, or where DANE should always be preferred over other modes of >> >authentication such as traditional PKIX) are thus not in its intended >> >scope. Such restrictive uses can however be supported >> >opportunistically. >> >> The last sentence makes no sense. The term "Restrictive uses" is poorly >> defined. The reduction in scope is effectively a reduction to just the >> cases where the extension is mandatory, if that's what you intend to do >> then say so (expect pushback). >> > Yeah, I agree the assertive and restrictive terms are poorly defined. I was using terminology that this WG has been using for a while, but we can reword. > >> Please do not imply that any non-mandatory "additive" use-cases are >> viable. They are not. >> > > I agree with Viktor here. > > You could imagine enforcing a restriction you see in a DANE extension the > cert you get milliseconds later, but that's pretty useless given that an > attacker can just not send the extension. Let's just scope this to the > additive case. > > This mean "additive" mandatory or non-mandatory, I assume. Viktor opposes the latter case, I assume based on his (unproven) assertion that there will no incentive to deploy this. I don't agree. Lots of sites already publish DANE for HTTPS records even before browsers can use them (IETF, freebsd, debian, torproject, defcon, ripe, etc). Once code is implemented/deployed they will be using it. Shumon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
On Sat, 28 Apr 2018, Shumon Huque wrote: I wish I could be confident that such a specification would be allowed to move forward. My fear is that the same visceral opposition to DANE and DNSSEC would play out, and so I may as well try to get past these now. I would like to explore this. Is there anyone in the working group who would oppose such a new spec moving forward? (Maybe the WG chairs need to ask this question officially). There is not much point in doing this, as everyone can "change their mind" later when this document's process has completed. In other words, it won't make me feel any better if no one objects now, unless the chairs would make it a discussion to update the TLS charter to add this work item. And even then, the more inevitable this new work item becomes, the more sense it makes to add the two bytes now to avoid more "designed by committee" weirdness like one extention mandating another extension and figuring out what it means if the mandating-extension itself vanishes. Our two byte proposal is technically sound. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft updates: tls-dnssec-chain
> On Apr 28, 2018, at 3:04 PM, Shumon Huque wrote: > > This mean "additive" mandatory or non-mandatory, I assume. Viktor opposes > the latter case, I assume based on his (unproven) assertion that there will no > incentive to deploy this.. I don't agree. Lots of sites already publish DANE > for > HTTPS records even before browsers can use them (IETF, freebsd, debian, > torproject, defcon, ripe, etc). Once code is implemented/deployed they will be > using it. My arguments are sound. Would you care to estimate what fraction of published _443._tcp TLSA records actually match the site's certificate chain? What non-hobbyist sites publish such records? It may be cool to play DANE for HTTPS when nobody is verifying, and there's no operational burden of keeping the records correct, (the one BENEFIT listed in my cost/benefit list), but real deployments need real incentives. With Let's Encrypt available, and no downgrade protection for HTTPS with DANE (via this extension) the incentive to support it is nil. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters wrote: > On Sat, 28 Apr 2018, Shumon Huque wrote: > > [ not going to repeat my technical arguments here, just going to comment > on process ] > > First, there is no agreement that your reason for doing pinning, >> i.e. that DANE needs downgrade resistance against PKIX attacks >> is even valid. >> > > This is incorrect. From the replies to the consensus call on the list, > it actually weights in favour of _some_ kind of downgrade resistance. > This isn't clear to me at all. What I observe is that some folks who don't want pinning in the draft are okay with it being an optional separate extension (which they can ignore, but others that want it can implement). Sadly, only a handful of people are actually participating on the list. What you are ignoring is the many people who spoke up in person at IETF/London against pinning. Most of those folks are not speaking up on list now. So if we do put the pinning field in this draft, what I suspect will happen is that it will be discussed at some future IETF TLS WG meeting, and will be shot down, and we'll be back to square one again, and this draft will never make progress. Thus my pragmatic side is encouraging going in the direction of the new extension, which I believe has more chance of success. Shumon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
> On Apr 28, 2018, at 3:28 PM, Shumon Huque wrote: > > Sadly, only a handful of people are actually participating on the list. > What you are ignoring is the many people who spoke up in person at > IETF/London against pinning. Most of those folks are not speaking up > on list now. So if we do put the pinning field in this draft, what I suspect > will happen is that it will be discussed at some future IETF TLS WG > meeting, and will be shot down, and we'll be back to square one again, > and this draft will never make progress. Consensus is verified on the mailing list. NOT in the room. If we get this draft revised promptly, I would expect it to complete the process before the next IETF in any case. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters wrote: > On Sat, 28 Apr 2018, Shumon Huque wrote: > > This can be clearly seen from various comments on >> list and at IETF/London, such as the point made many times that >> the original purpose of this draft was to add DANE as an additional >> possible authentication mechanism in TLS, not to position it as a >> mechanism that if available unconditionally trumps PKIX authentication.. >> > > This is actually upsetting. I can assure you that since the late 90's, > people were working on DNSSEC as an alternative for the webpki. I wrote > RFC 7901 as a building block for doing so, and that RFC is now the basis > of the format of the data in this document. It is an explicit goal of > _some_ people at IETF and has been for decades. What the motivation is > of the individual document editor is not relevant. Once the document > was adopted by the WG it became a document that needs to represent WG > consensus, not original author intent. > This is a case where clarifying the scope and limitations of the protocol from the outset would have been helpful. Many DNSSEC people I know who have followed this draft and participated in the much earlier discussions around DNSSEC stapling in certificates were acutely aware of lack of authenticated denial and its obvious implication that there was no downgrade resistance against PKIX. So I always assumed there was at least an implicit understanding of the scope. What greatly surprised me was that Viktor (and you) did not come to this realization until a few months ago (I believe that was shortly after I asked Viktor in private email to read the entire draft and I assume he came upon the text that described the issue, and the possibility of extending the protocol to include DoE later). We probably should have put this text in much earlier versions of the draft. Shumon ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
> On Apr 28, 2018, at 4:11 PM, Shumon Huque wrote: > > What greatly surprised me was that Viktor (and you) did not come to > this realization until a few months ago (I believe that was shortly after I > asked Viktor in private email to read the entire draft and I assume he > came upon the text that described the issue, and the possibility of > extending the protocol to include DoE later). In my case, too many of the available cycles for this document were consumed by the necessary, but not security relevant, discussion of the payload format, and I had no time left for take in the big picture. I wish it were otherwise. It would have been far better to deal with this at the outset... -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
