Re: [TLS] draft-thomson-tls-snip-01

[Ben Schwartz <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>