[onionmx] SRV and v3 onions

[meskio]

Quoting Daniel Kahn Gillmor (2018-12-18 21:46:05)
> On Tue 2018-12-18 13:09:43 +0100, meskio via onionmx wrote:
> > In sindominio we have added a v3 onion to our onionmx setup. And now I'm 
> > wondering what to do with our _onion-mx._tcp. SRV record.
> >
> > I'm tempted to put the v3 there. But seeing that the tor version in debian 
> > stable doesn't have support for v3 onions, I'm wondering how many things are 
> > going to break by that. (the one in stretch-backports does support v3)
> >
> > Is anybody publishing v3 onions in their SRV?
> > Are we assuming people uses up to date tor?
> > Should we keep the v2 in our record until most distros get a more modern version 
> > of tor?
> > Is it worth to consider how to publish more than one record?
> 
> The DNS is designed to support multiple records for any given record
> type and name, and SRV itself has its priority/weighting scheme designed
> to accomodate some flavor of load-balancing:
> 
>    https://en.wikipedia.org/wiki/SRV_record
> 
> So i see no principled reason that anyone *shouldn't* publish a v3 onion
> record.
> 
> That said, we might want to offer some guidance, both to publishers and
> consumers of these records.
> 
> barring reports of serious incompatibilities or failures in
> widely-deployed OnionMX clients, i'd recommend something like the
> following:
> 
> For SRV record publishers:
> 
>  * v3 onion address SRV records SHOULD have a lower "priority" field
>    than v2 onion address SRV records. (an RR with a lower-value
>    "priority" field is preferred over an RR with a higher-value
>    "priority")
> 
> For the consumers of SRVs -- do we need to give explicit guidance other
> than following the general suggestions for SRVs?  is there a situation
> where you'd want the the consumer of the SRV (the SMTP client) to
> prioritiize v3 onion addresses over v2 onion addresses even if the
> stated priorities suggest that the domain operator prefers the other
> order of prioritization for some reason?

I agree v3 records should be prioritized in an attempt to face v2 out.

Having a fast look into the code into the existing implementations[0][1] it 
looks like none of them acknowledges the priorities. The go implementation only 
uses the first found, the python interpretation looks like it might try all of 
the ones found.

I think adding a second record might break existing setups.


[0] https://github.com/ehloonion/onionrouter
[1] https://git.autistici.org/ale/postfix-onion-transport

-- 
meskio | http://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 My contact info: http://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists-7.immerda.ch/pipermail/onionmx/attachments/20181219/89057b08/attachment-0001.sig>