[GTER] uma ideia para discussão: SPF reverso.

[Henrique de Moraes Holschuh]

On 06-08-2012 15:05, Danton Nunes wrote:
> On Mon, 6 Aug 2012, Henrique de Moraes Holschuh wrote:
>> O reverso indica qual zona auxiliar utilizar. Zona auxiliar retorna
>> a informação de RSPF para todos os domínios que você quiser, por
>> exemplo, estilo RHSBL. *Aí* fica bem fácil fazer a coisa sem
>> tropeçar em nada exceto quem não tem SOA nem BCP-20 (que até eu
>> considero ser um caso pouco interessante). Aliás, dá inclusive para
>> reusar os softwares que implementam servidor de RHSBL (RBL de
>> domínio).
>
> vejamos. sou um cara mal intencionado e compro serviços IP de um
> fornecedor que me dá um /27. crio um par de chaves e mando para ele a
>  chave pública para publicar como validador de RSPF no seu reverso.
> Agora assino um PASS para gmail.com e saio enviando email como se
> fosse de fulano at gmail.com? é óbvio que não pode!
>
> outra coisa que preocupa é o fato da mesma chave poder ser dada para
>  mais de um ISP.
>
>>> propósito deste protocolo é ser simples e rápido, de preferência
>>
>> Esse protocolo é inútil se não houver adoção em massa. Vai com
>> calma, sugiro ter como objetivo uma versão já bem redonda para
>> pedir comentários na GTER do fim do ano...
>
> não sei o quanto essa dificuldade com os blocos />24 prejudicaria a
> adoção em massa. proponho o seguinte: implementamos uma versão sem o
>  esquema de delegação via chave pública (ou outro mecanismo de
> confiança a ser definido) mas com um gancho que permita que ele seja
> acrescentado depois. o esquema proposto é muito engenhoso, mas não
> está claro quais podem ser seus efeitos colaterais, especialmente a
> possibilidade do fornecedor de serviços IP acabar assinando uma
> procuração muito ampla ao publicar uma chave pública de um cliente.

Não use chave pública.  Se usar uma zona auxiliar, NÃO PRECISA DE NADA
DISSO.  Deixa a criptografia pro NSEC3 ;-)

A zona auxiliar é uma forma (que pode inclusive ser opcional, assim quem
não precisa, não cria carga extra de DNS) de mapear para fora do reverso
o espaço DNS que não dá para utilizar via BCP-20 sem a operadora mandar
você pastar.  Só isso.

Ou seja, poderia ser o esquema RHSBL que vocês bolaram, e que escala bem:

Sejam  x.invalid, y.invalid e z.invalid  três domínios que
enviam/recebem email.  "invalid" é uma TLD fictícia válida ;-)

Sejam  A, B, C os IPs (tanto faz se é IPv4 ou IPv6) de MTAs/MXs.

Sejam RDNS(A), RDNS(B) e RDNS(C) a base do DNS reverso de cada um desses
IPs (ou seja, a4.a3.a2.a1.in-addr.arpa. se A for um IPv4, por exemplo).

Sejam PTR(RDNS(A)) o RRset do tipo PTR retornado ao se consultar o nó
RDNS(A) no DNS.

Seja BCP20(RDNS(B)) a base do DNS reverso usada por B, e que é alcançada
via RR CNAME em RDNS(B).  RDNS(B) está sob controle da operadora.

A tem SOA do reverso, ou seja, pode colocar o que quiser em RDNS(A),
inclusive subzonas, como por exemplo qualquercoisa.rspf.RDNS(A).

B não tem SOA do reverso, mas recebe delegações via BCP-20.

C é um coitado que hospeda servidor de email em banda larga "comercial",
e abre chamado em 0800 ou usa formulário web para alterar PTR(RDNS(C)).

C dançou, e não pode usar RSPF nessa versão.  Quem sabe na versão 2.0 ;-)

B precisará utilizar uma zona auxiliar.

A utilizará a zona auxiliar somente se quiser.


RSPF (da ideia de vocês):

Suponha que o MTA A atende x.invalid e z.invalid.  Ele publicará:

x.invalid.rspf1.RDNS(A) IN TXT (politica para x)
z.invalid.rspf1.RDNS(A) IN TXT (politica para z)
                 RDNS(A) IN PTR nome1.canonico.de.A. (múltiplos PTR ok!)
                         IN TXT rspf1,direct,(politica geral)

Suponha que o MTA B atende y.invalid.  Ele publicará:
   BCP20(RDNS(B)) IN PTR nome1.canonico.de.B. (múltiplos PTR ok!)
                  IN TXT rspf1,auxz=baserspf.canonico.de.B.,(politica geral)

   y.invalid.rspf1.baserspf.canonico.de.B. IN TXT (politica para y)

   nesse caso, inclusive pode se obrigar que a zona auxiliar seja de
mesmo nível que um dos PTRs.  Não considero isso necessário.


Pronto.  E só usem TXT em último caso, retornar registros A para indicar
políticas específicas economiza bit no cabo e na RAM.  Inclusive porque
RSPF é para ser SIM/NAO para acabar com as besteiras estilo +all do
SPF...  Um exemplo seria seguir a linha das RBLs, e retornar
127.0.0.FLAGS, onde bit0(FLAGS) = MX(de entrada) OK, bit1(FLAGS) =
MTA(de saida) OK.  E NXDOMAIN significa "nem a pau juvenal").

>>> além disso eu gostaria de partir logo para experimentações,
>>> publicar registros, escrever um milter ou adaptar o spfmilter
>>> para tratar disto, afinal, vale o moto do IETF 'we believe in
>>> running code'.
>>
>> Ué, o que está impedindo isso? :-) Só não é boa ideia publicar o
>> troço em larga escala enquanto ainda não estiver redondo, ou vai
>> queimar o cartucho.
>
> já estou hackeando o spfmilter.

Manda ver.  O que descrevi acima reaproveita o código de RHSBL do MTA
inteirinho, você poderia começar com o caso A mas já prevendo no 
protocolo o caso B.

Note que quem for servir muitos domínios deve considerar a utilização de
um servidor de RHSBL como autoritativo para as zonas rspf1.<base>.

Proteção fica à cargo do DNSSEC e NSEC3, como deveria ser (conseguir que
operadora assine a zona do reverso no caso BCP-20 são outros quinhentos...)

-- 
Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464

Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.