Proposal for using NAPTR/URI records

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Proposal for using NAPTR/URI records

Nathaniel McCallum-5
Read the proposal here: http://k5wiki.kerberos.org/wiki/Projects/NAPTR

The main feature is to enable discovery of MS-KKDCP proxies. But it
also has side benefits of giving admins greater control over client
behavior.

Nathaniel
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nico Williams
Using NAPTR certainly takes MS-KKDCP from the realm of curiosity that
might turn out to be very handy, to the realm that requires
significant security review and treading carefully.

Even just plain URI.  The first thing that comes up is: OK, so I'm
discovering a proxy for a realm's KDCs, but how do I know what's safe
to expose to said proxy?  Should I always use FAST w/ anon PKINIT?
What is the complete list of what will leak?  When should DNSSEC be
required?

One might as well put capaths in DNS, with similar (further-reaching)
considerations.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Simo Sorce-3
On Mon, 2015-02-23 at 22:59 -0600, Nico Williams wrote:

> Using NAPTR certainly takes MS-KKDCP from the realm of curiosity that
> might turn out to be very handy, to the realm that requires
> significant security review and treading carefully.
>
> Even just plain URI.  The first thing that comes up is: OK, so I'm
> discovering a proxy for a realm's KDCs, but how do I know what's safe
> to expose to said proxy?  Should I always use FAST w/ anon PKINIT?
> What is the complete list of what will leak?  When should DNSSEC be
> required?
>
> One might as well put capaths in DNS, with similar (further-reaching)
> considerations.

I do not see how exposing KKDCP in DNS is any different from current DNS
SRV records, therefore I do not see why it requires additional security
considerations.

Can you explain ?

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nico Williams
On Tue, Feb 24, 2015 at 8:49 AM, Simo Sorce <[hidden email]> wrote:
> On Mon, 2015-02-23 at 22:59 -0600, Nico Williams wrote:
> > [...]
>
> I do not see how exposing KKDCP in DNS is any different from current DNS
> SRV records, therefore I do not see why it requires additional security
> considerations.
>
> Can you explain ?

Check out this thread (all of it, particularly Viktor D.'s and Sam
H.'s comments):

https://www.ietf.org/mail-archive/web/ietf/current/msg91915.html

It's not that it can't be done.  But that it requires care.

Again, if I use a locally-configured proxy, or a proxy that is
co-located with the KDCs of the target realm, then no problem.  If I
use a DNS RRset that could point to a different host, and to boot I
don't use DNSSEC, then I now I have a problem.

OTOH, it's probably not a big deal, we just need to think through the
security considerations:

 - TGS exchanges leak little information about the client principal
(mostly the Ticket they are using, and in the case of user2user
Kerberos, the user2user TGT of the peer).

 - AS exchanges leak the cname and crealm, but could be tunneled in
FAST w/ anon PKINIT, yielding protection for the cname, but not much
protection for the crealm (since, after all, if we're talking to an
MITM, they could have used a different host:port for each realm for
which they saw a query for a proxy).

 - anything else?

BTW, the better forum for this is the KITTEN WG list.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nico Williams
I should add that I'm assuming that an MITM wouldn't be able to get
away with modifying important bits of the protocol because we
authenticate all contents (or all that matters).  So the main problem
would be information leaks and other problems with getting redirected,
such as (stretching here) changing the trust anchors that the AS'
PKINIT cert is to get validated to.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Simo Sorce-3
In reply to this post by Nico Williams
On Tue, 2015-02-24 at 10:34 -0600, Nico Williams wrote:

> On Tue, Feb 24, 2015 at 8:49 AM, Simo Sorce <[hidden email]> wrote:
> > On Mon, 2015-02-23 at 22:59 -0600, Nico Williams wrote:
> > > [...]
> >
> > I do not see how exposing KKDCP in DNS is any different from current DNS
> > SRV records, therefore I do not see why it requires additional security
> > considerations.
> >
> > Can you explain ?
>
> Check out this thread (all of it, particularly Viktor D.'s and Sam
> H.'s comments):
>
> https://www.ietf.org/mail-archive/web/ietf/current/msg91915.html
>
> It's not that it can't be done.  But that it requires care.
>
> Again, if I use a locally-configured proxy, or a proxy that is
> co-located with the KDCs of the target realm, then no problem.  If I
> use a DNS RRset that could point to a different host, and to boot I
> don't use DNSSEC, then I now I have a problem.

Well given KErberos is built to run on untrusted networks ... I'd be
surprised if we have a problem. Esp with preauth and (in future) PAKE to
make things more robust.

> OTOH, it's probably not a big deal, we just need to think through the
> security considerations:
>
>  - TGS exchanges leak little information about the client principal
> (mostly the Ticket they are using, and in the case of user2user
> Kerberos, the user2user TGT of the peer).
>
>  - AS exchanges leak the cname and crealm, but could be tunneled in
> FAST w/ anon PKINIT, yielding protection for the cname, but not much
> protection for the crealm (since, after all, if we're talking to an
> MITM, they could have used a different host:port for each realm for
> which they saw a query for a proxy).
>
>  - anything else?

Ok so your concern is disclosure of information regarding realm and
client principal.

The realm is a lost cause, given you put the realm name in DNS to start
with. If you do that I think it is safe to assume the admin does not
have a problem disclosing the realm name.

The principal name is another story, but given that one is always leaked
(also when using SRV records) it is more a matter of local policy rather
than a problem with advertising via DNS.

It may make sense to warn admins that if they want more privacy they are
strongly advised to use FAST with Anonymous tickets as the armoring.
But that is a general privacy concern, I do not see it as specific to
the advertising of KDC locations/protocols via DNS.

> BTW, the better forum for this is the KITTEN WG list.

It may be a security consideration in an RFC if we come up with one,
agreed.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nathaniel McCallum-5
In reply to this post by Nico Williams
On Tue, 2015-02-24 at 11:15 -0600, Nico Williams wrote:
> I should add that I'm assuming that an MITM wouldn't be able to get
> away with modifying important bits of the protocol because we
> authenticate all contents (or all that matters).  So the main
> problem would be information leaks and other problems with getting
> redirected, such as (stretching here) changing the trust anchors
> that the AS' PKINIT cert is to get validated to.

MITM attack isn't a property limited only to MS-KKDCP. It is possible
at pretty much every level. Any attack possible over MS-KKDCP is
possible pretty much everywhere. In fact, I consider MS-KKDCP *more*
secure given that it goes over TLS and the TLS connection is validated.

Frankly, I'd like to see us drop the TLS requirement for MS-KKDCP...
But now I'm really stirring the pot. :)

The point is that Kerberos should always presume that transport is
insecure. Given this, adding additional hoops for a transport that
provides authenticated encryption for at least part of the journey
seems wrong.

Nathaniel
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Simo Sorce-3
On Tue, 2015-02-24 at 13:19 -0500, Nathaniel McCallum wrote:

> On Tue, 2015-02-24 at 11:15 -0600, Nico Williams wrote:
> > I should add that I'm assuming that an MITM wouldn't be able to get
> > away with modifying important bits of the protocol because we
> > authenticate all contents (or all that matters).  So the main
> > problem would be information leaks and other problems with getting
> > redirected, such as (stretching here) changing the trust anchors
> > that the AS' PKINIT cert is to get validated to.
>
> MITM attack isn't a property limited only to MS-KKDCP. It is possible
> at pretty much every level. Any attack possible over MS-KKDCP is
> possible pretty much everywhere. In fact, I consider MS-KKDCP *more*
> secure given that it goes over TLS and the TLS connection is validated.
>
> Frankly, I'd like to see us drop the TLS requirement for MS-KKDCP...
> But now I'm really stirring the pot. :)
>
> The point is that Kerberos should always presume that transport is
> insecure. Given this, adding additional hoops for a transport that
> provides authenticated encryption for at least part of the journey
> seems wrong.

It seem to me the problem here is understanding what assumptions are
being made here.

Nico, can you state on which assumptions you are making your comments ?
I can't see any *additional* attack introduced by MS-KKDCP, but it seem
you are assuming MS-KKDCP introduces additional assumptions I may not be
aware of.

Care to clarify ?

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Greg Hudson
In reply to this post by Nico Williams
On 02/23/2015 11:59 PM, Nico Williams wrote:
> Using NAPTR certainly takes MS-KKDCP from the realm of curiosity that
> might turn out to be very handy, to the realm that requires
> significant security review and treading carefully.

>From the perspective of our client code, MS-KKDCP is just another way of
communicating with the KDC, functionally equivalent to TCP or UDP.  We
do not transmit any information about the sendto-kdc channel up the
stack; for instance, the proxy's name or certificate does not have any
impact on PKINIT KDC cert validation.

Using MS-KKDCP can provide some security advantages (e.g. a passive
listener cannot as easily capture PA-ENC-TIMESTAMP messages to conduct
offline dictionary attacks against), but everything above the sendto_kdc
layer considers those advantages to be incidental benefits or
defense-in-depth.  Auto-discovering the MS-KKDCP proxy discards most of
these security benefits (unless DNSSEC is used, or a private CA is
configured for verifying the proxy server cert), but does not introduce
any new vulnerabilities relative to communicating over TCP or UDP, which
we are already willing to auto-discover.

Using MS-KKDCP also provides firewall penetration for certain classes of
firewalls.  This, and not the additional security benefits, is probably
the motivating use case for proxy auto-discovery.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nico Williams
In reply to this post by Simo Sorce-3
There is work under way to add confidentiality protection to DNS
queries and responses, FYI.

Basically, to make this work you'll have to say that DNSSEC support
and use on the client side is required (zones can opt-out, as always).
And you may have to say something about MITMs and sname leakage.
You're right that the srealm is probably a lost cause in all cases.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nico Williams
In reply to this post by Nathaniel McCallum-5
On Tue, Feb 24, 2015 at 12:19 PM, Nathaniel McCallum
<[hidden email]> wrote:
> MITM attack isn't a property limited only to MS-KKDCP. It is possible
> at pretty much every level. Any attack possible over MS-KKDCP is
> possible pretty much everywhere. In fact, I consider MS-KKDCP *more*
> secure given that it goes over TLS and the TLS connection is validated.

Yes, but we're working towards closing many MITM-on-the-wire cases.
DNSSEC takes care of one set of cases.  FAST takes care of the rest
(to some degree).  (IPsec is out; let's not mention it.)  Admittedly,
that's part of the answer to the problem here: use DNSSEC where zones
don't opt-out.

> Frankly, I'd like to see us drop the TLS requirement for MS-KKDCP...
> But now I'm really stirring the pot. :)

But I agree with this.  If we use FAST for AS *and* TGS exchanges,
then what do we get from TLS that we're not already getting from FAST?

This is important from an implementation complexity point of view.
It's a given that we'll all need DNSSEC, fine, and Kerberos, since
Kerberos is the point here, but why add a dependency on TLS?  That
brings in a whole bunch of things that a Kerberos implementor might
not want to have to deal with.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Simo Sorce-3
In reply to this post by Nico Williams
On Tue, 2015-02-24 at 12:47 -0600, Nico Williams wrote:
> There is work under way to add confidentiality protection to DNS
> queries and responses, FYI.
>
> Basically, to make this work you'll have to say that DNSSEC support
> and use on the client side is required (zones can opt-out, as always).
> And you may have to say something about MITMs and sname leakage.
> You're right that the srealm is probably a lost cause in all cases.

Sorry, but if you are using DNSSEC, MITM is not a problem, so
unfortunately I do not understand your concerns with more info on the
assumptions you are making.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Simo Sorce-3
In reply to this post by Nico Williams
On Tue, 2015-02-24 at 12:53 -0600, Nico Williams wrote:

> On Tue, Feb 24, 2015 at 12:19 PM, Nathaniel McCallum
> <[hidden email]> wrote:
> > MITM attack isn't a property limited only to MS-KKDCP. It is possible
> > at pretty much every level. Any attack possible over MS-KKDCP is
> > possible pretty much everywhere. In fact, I consider MS-KKDCP *more*
> > secure given that it goes over TLS and the TLS connection is validated.
>
> Yes, but we're working towards closing many MITM-on-the-wire cases.
> DNSSEC takes care of one set of cases.  FAST takes care of the rest
> (to some degree).  (IPsec is out; let's not mention it.)  Admittedly,
> that's part of the answer to the problem here: use DNSSEC where zones
> don't opt-out.
>
> > Frankly, I'd like to see us drop the TLS requirement for MS-KKDCP...
> > But now I'm really stirring the pot. :)
>
> But I agree with this.  If we use FAST for AS *and* TGS exchanges,
> then what do we get from TLS that we're not already getting from FAST?
>
> This is important from an implementation complexity point of view.
> It's a given that we'll all need DNSSEC, fine, and Kerberos, since
> Kerberos is the point here, but why add a dependency on TLS?  That
> brings in a whole bunch of things that a Kerberos implementor might
> not want to have to deal with.

Just for the record I'll add a me too, to the list of people that think
TLS should not be required for the MS-KKDCP protocol implementation, it
should be optional.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nico Williams
In reply to this post by Simo Sorce-3
On Tue, Feb 24, 2015 at 1:22 PM, Simo Sorce <[hidden email]> wrote:
> Sorry, but if you are using DNSSEC, MITM is not a problem, so
> unfortunately I do not understand your concerns with more info on the
> assumptions you are making.

The proposal did not mention DNSSEC.  I'm saying you'll need to say
something about at least that.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Simo Sorce-3
On Tue, 2015-02-24 at 13:42 -0600, Nico Williams wrote:
> On Tue, Feb 24, 2015 at 1:22 PM, Simo Sorce <[hidden email]> wrote:
> > Sorry, but if you are using DNSSEC, MITM is not a problem, so
> > unfortunately I do not understand your concerns with more info on the
> > assumptions you are making.
>
> The proposal did not mention DNSSEC.  I'm saying you'll need to say
> something about at least that.

You are still not saying why.
The NAPTR proposal does not seem to add any attack vector that is not
already present with the current DNS SRV record discovery mechanism that
is supported in MIT Kerberos and other implementations.
So I see nothing new that needs highlighting.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nico Williams
In reply to this post by Nathaniel McCallum-5
The other thing is: NAPTR is way too complex a beast, and if URI RRs
will do the trick, then please stay away from NAPTR.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nathaniel McCallum-5
----- Original Message -----
> The other thing is: NAPTR is way too complex a beast, and if URI RRs
> will do the trick, then please stay away from NAPTR.

By this, do you mean?

1. Look up SRV.
2. If SRV fails, look up URI.

If no, then what?

If yes, then please defined precisely what you do and do not mean by "fails."

Nathaniel
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nico Williams
On Wed, Feb 25, 2015 at 1:23 PM, Nathaniel McCallum
<[hidden email]> wrote:

>> The other thing is: NAPTR is way too complex a beast, and if URI RRs
>> will do the trick, then please stay away from NAPTR.
>
> By this, do you mean?
>
> 1. Look up SRV.
> 2. If SRV fails, look up URI.
>
> If no, then what?
>
> If yes, then please defined precisely what you do and do not mean by "fails."

I didn't say anything about failure.

Use URI RRs, but not NAPTR.  That's my take.

SRV RRs don't fit well because of the lack of a URI scheme (could be
http: or https:, but hopefully just http:) and the lack of a local
part (which can be overcome by using the port number and a fixed local
part, though it will upset some people, and perhaps rightly so).  If
SRV RRs are already in use for this use-case, so be it, but URI would
be more fitting for a standard.  NAPTR seems a little overwrought for
this use case, and anyways, it's the tool I'd reach for last: when
nothing else will work.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nathaniel McCallum-5

----- Original Message -----

> I didn't say anything about failure.
>
> Use URI RRs, but not NAPTR.  That's my take.
>
> SRV RRs don't fit well because of the lack of a URI scheme (could be
> http: or https:, but hopefully just http:) and the lack of a local
> part (which can be overcome by using the port number and a fixed local
> part, though it will upset some people, and perhaps rightly so).  If
> SRV RRs are already in use for this use-case, so be it, but URI would
> be more fitting for a standard.  NAPTR seems a little overwrought for
> this use case, and anyways, it's the tool I'd reach for last: when
> nothing else will work.
>

The problem is that SRV RRs are currently used for KDC discovery. But they can't represent a MS-KKDCP endpoint.

I'm happy to have a scheme like this and just use URI RRs:
  * krb5+https://kdc.example.com/kdc
  * krb5+http://kdc.example.com/kdc
  * krb5+tcp://kdc.example.com
  * krb5+udp://kdc.example.com
  * krb5://kdc.example.com

However, that wouldn't provide backwards compatibility with SRV. Also, MIT seems to be hesitant about adding any new method with higher priority than SRV search. Also, in the past MIT has expressed a dislike of the above types of URI schemes. I do think that the above scheme has the advantage of being able to set priorities (between transports) with a single RR.

Would MIT be interested in doing the above but making it a lower priority than SRV (for now)?
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for using NAPTR/URI records

Nico Williams
On Wed, Feb 25, 2015 at 03:22:20PM -0500, Nathaniel McCallum wrote:

> > Use URI RRs, but not NAPTR.  That's my take.
> >
> > SRV RRs don't fit well because of the lack of a URI scheme (could be
> > http: or https:, but hopefully just http:) and the lack of a local
> > part (which can be overcome by using the port number and a fixed local
> > part, though it will upset some people, and perhaps rightly so).  If
> > SRV RRs are already in use for this use-case, so be it, but URI would
> > be more fitting for a standard.  NAPTR seems a little overwrought for
> > this use case, and anyways, it's the tool I'd reach for last: when
> > nothing else will work.
> >
>
> The problem is that SRV RRs are currently used for KDC discovery. But
> they can't represent a MS-KKDCP endpoint.

We agree violently: your reply to this point restates mine without the
details :)

> I'm happy to have a scheme like this and just use URI RRs:
>   * krb5+https://kdc.example.com/kdc
>   * krb5+http://kdc.example.com/kdc
>   * krb5+tcp://kdc.example.com
>   * krb5+udp://kdc.example.com
>   * krb5://kdc.example.com

Wait a minute.  You want to _replace_ the existing SRV-based discovery
method for the _kerberos _udp and _tcp cases?  Is that right?  If so,
why?

My guess: to economize on DNS queries.  Of course, one could
send three queries concurrently, but the full set of possible
optimizations would be difficult to achieve.

So do one query for _kerberos.realm.name. looking for URI RRs, and let's
define a krb5 URI scheme, so that then we'd have:

  _kerberos.example.com. IN URI 1 1 http://kdc.example.com:1234/local-part
  _kerberos.example.com. IN URI 1 1 kdc:kdc.example.com:88/udp
  _kerberos.example.com. IN URI 1 1 kdc:kdc.example.com:88/tcp
  ...

One query gets you all the answers (or some, if you truncate, though if
you want DNSSEC you're probably not truncating).  If you find nothing,
then you query _kerberos.{_udp, _tcp}.example.com. and benefit from all
the cached records for ., com. and example.com.

BUT, since SRV is what existing installations have, the better way
forward would be to reverse this and first query for _kerberos.{_udp,
_tcp}.example.com. then _kerberos.example.com.

AND, since the client would start with the "legacy" queries, might as
well publish URI RRs there too:

  ; SRV RR for UDP
  _kerberos._udp.example.com. IN SRV 1 1 88 kdc.example.com.

  ; URI RRs for proxy, UDP, and TCP, why not?
  _kerberos._udp.example.com. IN URI 1 1 http://kdc.example.com:1234/local-part
  _kerberos._udp.example.com. IN URI 1 1 kdc:kdc.example.com:88/udp
  _kerberos._udp.example.com. IN URI 1 1 kdc:kdc.example.com:88/tcp

  ; SRV RR for TCP
  _kerberos._tcp.example.com. IN SRV 1 1 88 kdc.example.com.

  ; URI RRs for proxy, UDP, and TCP, why not?
  _kerberos._tcp.example.com. IN URI 1 1 http://kdc.example.com:1234/local-part
  _kerberos._tcp.example.com. IN URI 1 1 kdc:kdc.example.com:88/udp
  _kerberos._tcp.example.com. IN URI 1 1 kdc:kdc.example.com:88/tcp

Publishing extra RRs is cheap; extra queries are not.

This way we can have a single query get the client all the answers.

Let's call that the goldilocks proposal.

(A bit presumptuous.  Maybe it isn't quite just right yet.)

> However, that wouldn't provide backwards compatibility with SRV. Also,
> MIT seems to be hesitant about adding any new method with higher
> priority than SRV search. Also, in the past MIT has expressed a

No kidding: SRV is what existing clients do and what sites publish.

> dislike of the above types of URI schemes. I do think that the above
> scheme has the advantage of being able to set priorities (between
> transports) with a single RR.

I'm with them on this :)

> Would MIT be interested in doing the above but making it a lower
> priority than SRV (for now)?

See my goldilocks proposal above.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
123