Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Patrik Fältström <[e-mail]>]

On 28 aug 2013, at 14:24, S Moonesamy <[e-mail]> wrote:

> It's difficult, some might say impossible, to get agreement on draft-ietf-spfbis-4408bis.  I would like to ask each of you, and anyone else, to provide your opinion about the following:
> 
> RFC 5507 primarily raises three concerns about TXT records:

As the main editor of RFC5507 I might have a different view of what RFC 5507 says than others...but...that said, here are my comments.

RFC5507 first of all lists a number of prerequisites that should always be taken into account when extending the functionality of the domain name system. The intention was that the alternatives in section 3 where to be taken seriously as a way to solve the main problem, that the client when querying the DNS should be able to do a selection of what records the client needs by including the selector inside the triple {owner, type, class}. To solve that, there are a number of possible solutions.

Then there are specific discussions about the TXT resource record as you say, and those issues are included in the three issues you list below.

>  1.  The data in TXT is unstructured and subject to misinterpretation by other
>      applications.

The data is in fact structured, in the form of a series of strings, each one of them max 255 bytes long. But you are correct in the fact that RFC5507 does not go into those details. But, the SPF specification do not use this structuring that do exist, although it do (which is good) explicitly say that multiple such strings should first be concatenated before progressing with parsing the SPF record.

There is though no registry for the various formal uses of TXT records, and because of that there might be confusion among the various uses. Note that I am not saying that it is harder to write parsers, as for example an attacker can intentionally try to feed whatever data into whatever format a resource record do have. The parser must be robust regardless of the format.

Whether the SPF format itself is too complicated (I see various theoretical calculations on hundreds of RRSets be needed to get one SPF resolution correct) or not, that is *NOT* something I am evaluating here.

>  2.  Wildcard issues.

Correct.

>  3.  Size issues.

Correct, in two ways. It explicitly talks about the size of the TXT record, but RFC5507 also talks about the size of a Resource Record Set, which is what is returned to the client that queries. One also have to think about the size of the transaction, and specifically the complete response sent from the server, that contain multiple resource record sets.

I.e. we have:

3.1. The size limit 255 bytes for one string in the TXT record
3.2. The size of one TXT resource record (because the data is stored as text and not binary)
3.3. The size of a resource record set with the same owner, type and class
3.4. The size of a response to a query for a specific owner, type and class

> The draft addresses (3) by discussing size considerations, and tangentially addresses (1) in Section 3.4.

If we take the size issue first (3) it sort of looks at all of (3.1)-(3.4) above but not in a very clear way. The discussion in specifically section 3.4 is very confusing. It mixes up DNS response size with UDP payload size with MTU size. Because the text is not clear in its assumptions, it is very hard to say whether one agree or not with the conclusions. In turn, that leads to it being even harder to decide whether one agree or not with the conclusions on being as backward compatible with "old implementations" as is claimed being a necessity. I.e. there are a lot of claims in 3.4 based on unclear assumptions.

Further, if 3.4 is looking at the full response size, then it should also look at the response size in a similar way that has been done for DNSSEC, where also DNSSEC material is part of the response size (but then of course EDNS0 is in use).

Regarding the structure of the data, (1) above, it touches on it in section 3.3 and 3.4, but in reality the structure is really up to the parser and I think that is for this discussion sort of a non-issue.

I am more worried over (3.3) above, which is the core of RFC5507 that is really a problem, specifically together with the lack of a registry for the selectors that is part of the RDATA. If we compare with the other experience we do have, NAPTR, where this problem is a fact, we at least have a registry for the selectors so that we do know there will not be any collisions.

Yes, I do know SPF syntax do have an ability to refer to a record with a prefix, but that does not really help as the large RRSet is sent back in the response already to the first query.

> I would like to ask everyone not to turn this into a debate by not discussing about the opinion stated by someone else.
> 
> Regards,
> S. Moonesamy (as document shepherd)

   Patrik