[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

This is explicitly prohibited rfc9460 as it would provide linkability. So what? We’re not the protocol police and if someone wants to track, RFC9460 compliance isn’t going to stop them. Especially for something as controversial as ECH. ___ DNSOP mail

[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

* I would not be in favor of this. This is been intensely controversial and I want the document done I agree. The PR acknowledges the issue and that’s enough in my view. Any additional work on how to deploy something in DNS will require close coordination with the DNS folks and add an inte

[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

On 10/4/24 15:58, Salz, Rich wrote: > I disagree. It will show that some concerns have been heard, if not > addressed. Comity is all to rare these days. On 10/4/24, 11:03 AM, "Stephen Farrell" wrote: > Sorry, what's the "it"? (Apologies if I missed some > spe

[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

I don't really think it's helpful to re-litigate the broader topic of the merits of ECH; nothing we say in security considerations will make a material difference there. I disagree. It will show that some concerns have been heard, if not addressed. Comity is all to rare these days. ___

[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

I do not think this conflict of views can be resolved. The draft is intended to show how it ECH should be used to preserve it’s security guarantees, and there are groups in the DNS community who say this prevents their normal course of operation, and providing the features that they provide. I

[DNSOP] Re: [TLS] Re: AD review draft-ietf-tls-svcb-ech

We could add a recommendation like "Clients using ECH SHOULD select a DNS resolver that they trust to preserve the confidentiality of their queries and return authentic answers, and communicate using an authenticated and confidential transport", but this draft seems like an odd place for that te

[DNSOP] Comment on https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/

I'm not a member of this group, but I just saw the notice about this draft in the internet-drafts mailing list. FWIW, I'm one of the designated experts for the TLS registries and have lots of experience with them. You should add text in the IANA considerations saying that "{THISRFC}" is part of

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

> I would say that if the WG didn't think it was important at the time by forgetting it, it probably is not an "important term", and I can see this not being fixed in an IETF LC anymore as an acceptable outcome. Sure, if I'm in the rough that's fine. __

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

>> On the other hand, spending a week or two repeating a cycle to get an >> important term in the current document seems like a better solution. > If the WG agrees that this is an important term, sure. Well, if the IETF has consensus :) I'm raising the issue during this last call that "round

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

> This is the first time someone has suggested this, even though you're right > that it is a term we still sometimes here. I think it is unwise to add this > this late in the review cycle (it's already on the telechat agenda, and a new > definition would have to go back to the WG), but we'll try

Re: [DNSOP] [Last-Call] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04

>FWIW, I think asking CFRG for comment (not approval) whenever a new algorithm is introduced onto the standards-track is a good idea, regardless of the WG from which the draft came. Such checks don't mean anyone thinks badly of any algorithm, the argument is it's better to ask a

Re: [DNSOP] [Last-Call] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04

There is a fair amount of academic study around SipHash, and while everyone can make mistakes, its creators have a pretty good reputation. I don't think we can say SipHash is unknown in the industry. The TLSWG made it a practice to ask CFRG to "approve" all crypto it used (except perhapd HKDF,

Re: [DNSOP] [Last-Call] Secdir last call review of draft-ietf-dnsop-server-cookies-04

https://www.aumasson.jp/siphash/ * It seems like kind of a problem to have a normative algorithm reference to a random personal Website. That web page has

Re: [DNSOP] [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01

I think the issue about signature contexts first, and mainly, came up with TLS which generates a variety of private key material based on shared secret info, and the concern that those different keys could be used for cross-protocol attacks. But I could be wrong. :) -- Senior Architect, Ak