Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-00.txt

[Ted Lemon <[e-mail]>]

Right, I remember the discussion now.   But service registration is always
limited to the administrative domain.   Your objection doesn't really make
any sense.   This is not DNS update.   This is DNSSD Service Registration.
 It's only for service registration, and services are registered where they
are present, not across the Internet from somewhere else.   If you think
there's a SRP that works from random locations in the Internet, you should
write up the use case and we can talk about it.   But I think it would be
the protocol that would require the special name, not this one.

Also, I think Stuart and I both count as 1, so it's 2:1.   :)

On Wed, Oct 24, 2018 at 4:35 PM Tom Pusateri <[e-mail]> wrote:

> Looking at the archive, Toke was the only other person that commented and
> he didn’t specifically comment about the name, just that he supported
> adoption.
>
> So that’s 1-1 not counting the authors.
>
> Maybe encryption was more specific than I meant to state as a concern.
> From the document:
>
> "SRP updates have no authorization semantics other than first-come,
> first-served.  This means that if an attacker from outside of the
> administrative domain of the server knows the server's IP address, it
> can in principle send updates to the server that will be processed
> successfully.
> Servers should therefore be configured to reject updates from source
> addresses outside of the administrative domain of the server.”
>
> The main problem is that it’s restricted to an administrative domain.
>
> And previously, you stated that encryption would break the goals of the
> protocol because it’s supposed to be done in a single message which can’t
> happen when using DoT.
>
> Tom
>
> On Oct 24, 2018, at 3:55 PM, Ted Lemon <[e-mail]> wrote:
>
> Hm, my recollection is that there was a long discussion on the mailing
> list, and you were the odd man out.   In any case, SRP can be done over
> DoT, so encryption is certainly possible if required.
>
> On Wed, Oct 24, 2018 at 2:13 PM Tom Pusateri <[e-mail]> wrote:
>
>> If you were present in Montréal, you may remember that I supported this
>> work for adoption but wanted to see the named changed.
>>
>> There didn’t seem to be any other responses one way or the other. Since I
>> believe in rough consensus, it would be good to know if others feel the
>> same.
>>
>> The discussion was then moved to the list and can be found in the
>> archives.
>>
>> My main objection was that because it wasn’t possible to use encryption
>> with this scheme, it was not a general purpose solution and had to be
>> restricted to a subset of the use cases. Therefore, it should have a name
>> that reflects it’s inherent limitations.
>>
>> Thanks,
>> Tom
>>
>>
>> > On Oct 23, 2018, at 11:49 AM, [e-mail] wrote:
>> >
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> > This draft is a work item of the Extensions for Scalable DNS Service
>> Discovery WG of the IETF.
>> >
>> >        Title           : Service Registration Protocol for DNS-Based
>> Service Discovery
>> >        Authors         : Stuart Cheshire
>> >                          Ted Lemon
>> >       Filename        : draft-ietf-dnssd-srp-00.txt
>> >       Pages           : 19
>> >       Date            : 2018-10-23
>> >
>> > Abstract:
>> >   The Service Registration Protocol for DNS-Based Service Discovery
>> >   uses the standard DNS Update mechanism to enable DNS-Based Service
>> >   Discovery using only unicast packets.  This eliminates the dependency
>> >   on Multicast DNS as the foundation layer, which greatly improves
>> >   scalability and improves performance on networks where multicast
>> >   service is not an optimal choice, particularly 802.11 (Wi-Fi) and
>> >   802.15.4 (IoT) networks.  DNS-SD Service registration uses public
>> >   keys and SIG(0) to allow services to defend their registrations
>> >   against attack.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/
>> >
>> > There are also htmlized versions available at:
>> > https://tools.ietf.org/html/draft-ietf-dnssd-srp-00
>> > https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-00
>> >
>> >
>> > Please note that it may take a couple of minutes from the time of
>> submission
>> > until the htmlized version and diff are available at tools.ietf.org.
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > dnssd mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/dnssd
>>
>> _______________________________________________
>> dnssd mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>
>
>