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

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 Jan 2021 17:45:03 +1100

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

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 6 Jan 2021 12:02:20 -0500

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 <[email-masked]> wrote:

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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 07 Jan 2021 10:55:51 +1100

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:
> 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.
> 
> "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.
> 
> Attachments:
> * smime.p7s