Re: [TLS] Why TLSA RR and not CERT RR?
> On 26 Jun 2022, at 14:32, Robert Moskowitz wrote: > > So where do I ask where CERT records are being used? Maybe in the dnsop WG. Or at the DNS-OARC meeting immediately after IETF114. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] draft-rhrd-tls-tls13-visibility at IETF101
> On 13 Mar 2018, at 14:21, Stephen Farrell wrote: > > Just to be clear: I'm still waiting for the chairs and/or > AD to explain how the proposed discussion of this draft > is consistent with IETF processes, given the results of > the discussion in Prague (a very clear lack of consensus > to even work on this topic), and the discussion of the > -00 version of this late last year. IOW, I don't consider > my objection has been answered. Stephen, the opposite PoV is equally valid. There was no consensus in Prague NOT to work on the topic. The mood of the room was evenly divided. IIRC the supporters of draft-green-tls-static-dh-in-tls13 agreed to drop that draft and come back with a new one which would hopefully be more likely to get WG consensus. That draft has now arrived. It’s unreasonable to deny the new I-D a fair hearing and even worse to reject it out of hand. signature.asc Description: Message signed with OpenPGP ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
> On 19 Mar 2018, at 15:18, Dan Brown wrote: > > PS: I never directly worked on enterprise security (usually, I just think > about the math of basic crypto primitives), but I don't recall hearing about > such a "visibility" feature in the enterprise security work of colleagues > (whom I do _not_ speak for), e.g. one system used forward-secure ECMQV to > establish a connection between smartphones and the enterprise network. Hearsay anecdote is not evidence. :-) There are use cases in enterprise networks, notably in banking and finance. Some of these were presented to the TLS WG. [See Steve Fenter’s presentation at IETF97.] However the WG did not reach consensus on adopting the relevant drafts as work items. signature.asc Description: Message signed with OpenPGP ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Enforcing Protocol Invariants
On 8 Nov 2018, at 08:44, Ryan Carboni wrote: > > This might be a radical proposal, but maybe the certificate hash could be > placed in a DNS TXT record. This is a bad idea. Overloading TXT records with special semantics rarely, if ever, has a happy ending. For instance application software would need to somehow work out which of the TXT records for some domain name was your hypothetical hash and which were SPF strings or whatever else has been dumped into TXT records. If you need to put this hash in the DNS, you might as well get a type code assigned for a specifc RR to do that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
I’ve got a few concerns/issues with the document. 1) There probably needs to be clearer guidance about the use cases for this extension and the trade-offs between TLS clients doing DNSSEC validation for themselves instead of sending DNS lookups to a validating resolver server. How does an application developer decide which approach would or wouldn’t be appropriate? 2) I’m not sure there is much of an "associated latency penalty” from DNS lookups. Something’s going to esxperience this one way or another. Either the TLS client takes that hit or the TLS server does it for them before it sends back the requested DNS data. And in both cases, whatever is making the DNS lookups should be benefitting from what’s in the resolver’s cache. That cached data may even have been validated too. 3) Something should be said about algorithm agility. We can be reasonably sure web browsers, DNS servers, smart phones and so on will generally have up-to-date DNSSEC validators and/or TLS code. Some TLS clients -- fire and forget embedded systems, IoT devices, etc -- might never get updated once they’re deployed. If these clients use their own DNSSEC validators, they will be screwed when/if DNSSEC drops SHA1 signatures (say) or adds a new flavour of ECC or even an all-new signing protocol. 4) It’s not clear if TLS clients can or should cache the DNS data (and the resulting validations?) returned though this extension. Suppose a jabber client validates foo.com, does it have to start at the root and work all the way down to validate bar.com? Could it start that validation at the previously validated and new cached trust anchor for .com? Can/should negative answers -- NOHOST/NXDOMAIN responses -- be cached? 5) How does a TLS client behave when its DNSSEC validation of a TLSA record or whatever fails? Can/should it give up or fall back to conventional validation of the certificate via a CA? 6) The draft doesn't seem to take account of key rollovers when DNS data will be signed by two or more keys. Zone signing keys are missing from the examples too. These might well have been omitted for cosmetic reasons. IMO they need to be included in the final document to illustrate what implementers can expect to find when the DNS returns signed data. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
> On 5 Jul 2017, at 18:12, Viktor Dukhovni wrote: > > On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote: > >> 1) There probably needs to be clearer guidance about the use cases for >> this extension and the trade-offs between TLS clients doing DNSSEC >> validation for themselves instead of sending DNS lookups to a validating >> resolver server. How does an application developer decide which approach >> would or wouldn't be appropriate? > > On today's Internet, DNSSEC is not generally available to end-user > devices. There are too many "last mile" problems. Thus, while > direct acquisition of DANE TLSA records works for (e.g.) dedicated > SMTP servers, any end-user application that wants to do DANE TLS > needs to use the proposed extension. I am too painfully aware of those last mile issues. IMO the draft could be clearer about the fact it’s aimed at TLS clients that don’t have access to or a trust relationship with a validating DNS resolver. It might also be worthwhile explaining the trade-offs between the DNSSEC lookup and TLS chaining approaches and how an implementer or operator can choose between them when/if both are available. Though if the spec was to say “don’t bother with DNSSEC lookups at all and just use this chaining extension”, that would be fine. > Perhaps you're asking whether once the relevant records are obtained, > their validation should be via library calls to a suitable API, or > via a suitable protocol to the local resolver? No. I couldn’t care less about API issues or how the RRSIGs get validated. They’re implentation details for the implementation detail. I am uneasy at the prospect of every TLS client application include what will be essentially its own validating DNS resolver when there could/should be one of these already running on the device itself. > Except that the records will be warm in the server's cache, since > many clients will be asking it for the *same* data. The same is > not as likely to be true at the client. So there is indeed a likely > latency reduction in farming out the lookups to the server. OK. It might be helpful to explicitly say “TLS server” rather than “server” to avoid confusion or ambiguity. Sometimes this is obvious from the context. But at other places in the draft “server” could be read as “DNS server”. >> 4) It's not clear if TLS clients can or should cache the DNS data (and >> the resulting validations?) returned though this extension. > > The server will return TTLs, and caching per those TTLs is no less > appropriate than it is in DNS generally. Is there some reason why this isn’t in the draft? >> 5) How does a TLS client behave when its DNSSEC validation of a TLSA record >> or whatever fails? Can/should it give up or fall back to conventional >> validation of the certificate via a CA? > > This is application/configuration dependent. That probably needs to be captured in the document too. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
> On 7 Jul 2017, at 02:47, Shumon Huque wrote: > > I assume you're referring to the examples in Appendix D (Test Vectors)? Yes. > These are working examples that implementers can test code against. But it > looks like the testbed involved in these examples uses combined signing keys > (i.e. ones that are both the zone's secure entry point and the ZSK). Perhaps > we should use an example with the KSK/ZSK split to make them look more like > the real world. Let me discuss with Willem Toorop (co-author) who generated > these ... Willem told me he’d used the KSK as the ZSK for cosmetic reasons. Examples showing the KSK/ZSK split would show how things generally work the real world. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
> On 7 Jul 2017, at 16:06, Shumon Huque wrote: > > IMO, the real gain from having the client cache data, is that the server > could then potentially send a much smaller DNSSEC chain. But this requires > the client to signal what they've cached, and makes the protocol more > complex. I would prefer to leave that to a future revision of the spec, after > we've gained some operational experience with the current one. Shumon, I think the biggest gain would be fewer RRSIGs for the client to validate. Having the server send a smaller DNSSEC chain (and perhaps add something to the protocol for a client to signal that) probably won’t have the right cost/benefit optics. YMMV. It would be a Good Thing if a TLS client didn’t need to revalidate everything in the chain for tlsa.foo.com after closing and reopening a TLS session to that end-point or it could start at the previously validated delegation for .com when the TLS server returned the full chain for tlsa.bar.com. As you hint at, it would be good to get more data and operational expertise. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
