Your responses here reveal a lot of the assumptions that you're reading in here that are not actually true, e.g., those noted below.
On Wed, Sep 12, 2018 at 8:56 PM Paul Wouters <p...@nohats.ca> wrote: > On Wed, 12 Sep 2018, Richard Barnes wrote: > > > Speaking as one of the attendees, I do not agree with that conclusion. > > > > What came to light in that meeting is that the assertive cases of DANE > require that the certificate > > That is not what came to light. What came to light was that the > assertive use case does not exist because all TLSA selectors restrict > and that restriction is bypassed when you can force a client not to see > it. Unfortunately, there is no recording and no minutes, so we will redo > that discussion on Friday for the record. > > > verification in question use the provided cert / trust anchor. That > does not imply any semantic beyond a > > single TLS connection; there is no inherent need for pinning. > > DNS records have semantics beyond a single connection. DNS records have caching semantics. Those are only relevant for DNS resolution. This is the TLS WG, not the DNS. > You cannot tell > whether the TLSA records were obtained via direct DNS queries or the TLS > extension. So you can never make a decision based on purely requesting > the exention and not getting the extension in an answer. The > authoritative source is the DNS. This TLS extension is for those clients > who cannot get native DNSSEC and/or want to reduce round trips. What you > don't want is an attacker to be able to filter the TLS extension out, > thereby removing the TLSA Usage Selectors that restrict the CA, the > EEcert or the public key. That is a classic downgrade attack. > > > The "downgrade" here is simply that the client accepts a certificate > from a trust anchor it trusts. > > A zone owner published a TLSA record. A zone owner sent a TLSA record in a TLS handshake. This document says nothing about what is "published" through any other channel. > They configure their TLS server to > transport this information. It pins the certificate or root certificate. > Someone managed to undo the TLS server extension. The added TLSA security > is removed by the attacker, while the TLSA data remains active in the > DNS zone. The zone owner's security has been downgraded to "as if no > TLSA record was published". It removed the TLSA restrictions. It's a > downgrade attack. > > > I do not agree that we should include the SupportLifetime element. TBH, > I'm kind of puzzled that it's in > > here. > > Because I know of only 2 people objecting, and both people have not > articulated their concerns beyond handwaving, claiming they explained it > and refuse to point out where in the TLS list of TLS meeting minutes they > conveyed this information. I don't know where to get this information so > I cannot evaluate it. It would be helpful if you can provide it. Either > a link to previous explanations or a newly written summary would work > for me. What does not work is stating "it is kind of similar to HKPK > and that didn't work, so this wont work either". > I don't seem to recall you having rebutted that point, though. > > It is no different from what has been proposed in the past. No attempt > has been made to address the > > issues that were raised by EKR, me, and others. And there is clearly no > consensus for it. > > Please provide a link to the "issues raised" by you or ekr or the others > that convey why this simple two byte value won't do. Please refrain > from comparision to other vaguely similar protocols and state clearly > the problem with this suggested protocol change, The similarity isn't vague; the problems are identical. Let's look at the Chrome intent to remove HPKP https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ?hn They cite, for example: """ - There is a risk of rendering a site unusable. - There is a risk of hostile pinning, should an attacker obtain a misissued certificate. While there are no confirmed or rumored cases of this having happened, the risk is present even for sites that don’t use PKP. """ Both of which are also problems with your pinning proposal. > taking into account > that the pinning is for the extension support, and not for pinning any > data whatsoever as the live DNS is the only authoritative data for TLSA > records. We added text that describes how to remove the extension > pinning if you want to do that and describe clearly that you at any > point in time without waiting on anyone or anything else, can remove the > TLSA record from your DNS zone without breaking anything. > > > It would be more productive for the group to consider a PR without that > addition, that is focused on > > clarifying that clients should not cache the information they get in > this way > > Any client that obtains DNS data with a valid TTL is allowed to cache > and re-use it as long as the TTL allows it. Irrespective of whether this > is part of TLS or Aviation Carriers. The client may do that. That doesn't mean the server is entitled to expect the client to do that. And if the server doesn't expect the client to cache, then there's no downgrade at all. > Therefore your statement that the > client should not cache DNS data is fundamentally wrong and would go > against normal operation of the DNS protocol. > > > and clarifying the > > relationship between this extension and record fetching via the DNS > protocol. > > I thought we clarified it? The TLS client works from its DNS cache. It > can decide how to query for TLSA records. It can use regular DNS or this > TLS extension. Or Tor. Or blockchain. When it receives the data and > validates it, it can use the information and put the data in its cache > for the remaining TTL time. For new TLS connections to the same origin, > it can re-use the DNS data from cache and choose to omit the TLS > extension completely while _still_ using TLSA record information to > require a pinned CA or EE cert, thus protecting against a WebPKI > compromise. > > Paul >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
