Re: 15 reasons for using URLs/HTTP

On Thu, Feb 12, 2004 at 01:10:00PM -0800, Mark Baugher wrote:

> At 11:15 AM 2/12/2004, Hadmut Danisch wrote:
> >
> >I received several comments to my proposal
> >to move from DNS to HTTP for fetching the authorization
> >records.
> 
> This is where I am lost.  Authorization is based on some kind of trust, 
> i.e. "trust to do what?"  For example, with DNS, we trust the binding of a 
> name to an address is correct, and with reverse DNS we trust the binding of 
> an address to a name.  What do you propose to replace this with when you 
> move from DNS, which is a global database system based on IANA assignments, 
> to http, which is a client/server protocol?

"Trust" is the wrong word, it has some meaning which is not well
defined. "Trust" is usually avoided in security context, and
if it is used then it means that you rely on someone else to
behave well, e.g. you trust someone else to not generate false 
PGP certificates or something like that. That's why you're confused.

A simple rule to help understanding:

"Authentication" is answering the question "Who are you?", 
were any kind of identifier is (more or less) reliable 
(means: difficult or impossible to forge) determined.
Done with e.g. a password or cryptographical challenge response
protocols.

"Authorization" is the next question: Once we determined 
who we are talking with (through authentication), we can 
lookup what this particular entity (person,...) is 
permitted to do. This is usually any kind of database 
lookup.


Now, as with many other protocols, authentication is a little
bit difficult, because it happens implicetely. The identifier
is _not_ the e-mail address, it is the IP address. This is 
the authenticated identifier. How is it authenticated? 
The TCP sequence number is a kind of poor challenge response
mechanism. You can correctly perform the handshake only after
you received the package that was sent to you before 
(except for routing attacks and weak sequence numbers). 

Therefore, when receiving a TCP connection, then the operating
system has implicetely done a (not strong, but better than 
weak) authentication, and the result is the IP address of the 
peer, which you can get with the getpeername() system call. 

That's why it is difficult to understand, because all this 
happens outside the application and not as part of the mail 
protocol, but the underlaying transport.

So when the MTA gets the SMTP connection, this special kind
of authentication is already done.

What were are here talking about is that second question:

We know that we are talking with a.b.c.d and a.b.c.d is
requiring to make use of the right to use a particular
e-mail address for sending a message. Who is competent 
to permit this? The domain owner. How do we find him?
DNS. So we have to ask him: Whom do you grant permission 
to use this e-mail address/domain for sending e-mail?

The domain owner now gives an explicit technical 
statement, who is permitted = who is authorized. This
statement is what I use the term Authorization Record
for.

That's why it is "Authorization" what we all are talking
about here.



Where do I want to move from DNS to HTTP?

Reconsider what I was writing above: Two steps are to be done,
1. find the domain owner or his statement
2. transmit the statement


For the first step, I still stick to DNS, because that's what
DNS is designed to do and that's what DNS does pretty well.
I expect the domain owner to store the information in DNS where 
to find the Authorization record.

But I do not (longer) agree that it is in any case a good idea
to also keep the authorization record itself in DNS, because 
DNS is not a general database.


Let me give an example: If you want to get someone else's 
homepage. What do you do (what does the Browser do)?

First, you ask the DNS where to find it. Good.

Second, you use a different, appropriate protocol to transport
the data. Here: HTTP

Would you ever put your home page in your DNS zone file instead
on your web server? Or images of your photo album? A sound file?
No? Good. But why do you want to put an authorization record in 
DNS then?

I admit that I have changed my mind.

When developing RMX I had in mind to keep records very compact
and condensed to make them fit into DNS. 

Meanwhile many people told me that they do not want to 
have a new RR type, and that they want to use TXT instead.
And there are a lot of proposals  where the record grows bigger
and bigger. And most of the proposals just differ in the 
way of trying to encode the authorization record in RR types 
which are not supposed to carry that kind of information. 
Microsoft's CallerID tries to make a text file out of several 
TXT entries, and recently there was a proposal about storing 
the number of lines in the lower two bytes of an A ptr. 

That's not good engineering. It shows that this is a wrong 
approach. DNS is good to localize resources like authorization
records, but not to store them.

regards
Hadmut