Re: 15 reasons for using URLs/HTTP

At 03:23 PM 2/12/2004, Hadmut Danisch wrote:
>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

Well, this statement isn't too hard to disprove.  Let's see, the last thing 
I read today...
http://josefsson.org/thesis/josefsson_simon_master_thesis.pdf
has 31 occurrences of the word "trust."

My favorite reference lately is the Handbook of Applied Cryptography, 
http://www.cacr.math.uwaterloo.ca/hac/ , which has several chapters about 
the T word, such as "13.6.1 Trust between two domains"

I like to use the word myself in security contexts, 
http://www.ietf.org/rfc/rfc3547 , 
http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-09.txt - odd that 
no one in the IESG security area coached us to avoid the word trust.

>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.

Yes, but at least I'm well read on the topic of security.

Mark


>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