Hi Ben, Thanks for your input.
As I am currently dealing with a DoS from the IESG, I'm going to just file issues for these and promise to get back to you. (You are flagged on them, and I've included some off-the-cuff responses there in case you want to add more.) On Thu, Jan 7, 2021, at 04:02, Ben Schwartz wrote: > Hi Martin, > > Thanks for the update. I agree this is clearer. > > I'm having trouble understanding the "default authentication scope". > How can this be a useful construct, if clients and servers are both > forbidden from using it? > > Section 7 says that ordinary connection to a service by its AAAA record > and a well-known port "does not provide enough information to locate > other incompatible protocols". That seems like a convention, rather > than a matter of fact. > > Overall, I still think SNIP would be more useful if it focused on the > scope of "same IP and port number", which would minimize coordination > problems and increase utility in most use cases. That happens to be > the effect of the "QUIC" scope anyway. I would call this the "default" > scope. > > BTW, Section 6.2 seems to assume that all ServiceMode (formerly > "ServiceForm") SVCB records in an RRSet have the same TargetName > (formerly "SvcDomainName"), but that is not required. The scope as > currently defined is effectively "same IP", which is narrower. > > On further consideration, I think a SVCB scope may be unworkable. > Consider a CDN customer who copies the CDN's ServiceForm RRSet into > their own domain, and (alas) fails to keep it up to date. If the CDN > adds a new incompatible protocol, everything will work fine, but SNIP > will flag this as an attack, possibly making the customer's site > unreachable. > > The problem is that the SVCB scope doesn't identify _which_ SVCB RRSet > it's referring to, and it's not always easy to enumerate all the SVCB > RRSets that include a particular endpoint. > > On Mon, Jan 4, 2021 at 1:45 AM Martin Thomson <m...@lowentropy.net> wrote: > > Hi all, > > > > I've refreshed this draft: > > > > https://datatracker.ietf.org/doc/draft-thomson-tls-snip/ > > > > Synopsis: This describes a method for protecting against downgrade attack > > when protocols are in some way incompatible such that ALPN cannot provide > > that protection. > > > > This revision is an attempt to more fully and clearly describe how this > > works. I'm still not entirely happy with how this explains itself, but it > > should be marginally clearer now. > > > > Cheers, > > Martin > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > Attachments: > * smime.p7s _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
