Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framewo

On 28 aug 2013, at 14:24, S Moonesamy <sm+ietf(_at_)elandsys(_dot_)com> 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

signature.asc
Description: Message signed with OpenPGP using GPGMail