headers
Niall O'Reilly | 1 Mar 2011 01:37
Picon
Favicon

Re: I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

On 27/02/11 20:08, Patrik Fältström wrote:
> There are a few things I think makes this discussion hard...and that
> is that the overall usability is a requirement in the usability,
> manageability etc while what we talk about is "only" what we do in
> DNS. What we should (and can) do in DNS must then match whatever
> application layer/protocol behaviour, which in turn depends on how
> the protocol works.

	Or, should we look at the use cases at a higher level,
	and identify which components, including (but not limited to)
	the DNS, need to be adjusted to achieve the desired result?

	In this case, the question becomes no longer one of matching
	the DNS to how the other components actually work, but to
	how they will work in the future to support a coherent, rather
	than a fragmented, "aliasing" concept.

	I'm pretty sure that solving "the aliasing problem", whatever
	it is, cannot be done by adjusting only the DNS.

> What I *think* could be interesting is one of these things as very
> high level issues to look at, that btw I think sort of is written in the
> draft, but using DNS terminology ;-)

	I'm not sure quite what you're saying.

	Expressing higher-level issues in DNS terminology can either
	help us to visualize those issues, or blind us to the non-DNS
	aspects;  perhaps both of these effects occur at the same time.
(Continue reading)

Permalink | Reply | 33 comments |
headers
Alex Bligh | 1 Mar 2011 10:28
Picon

Re: I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt


--On 1 March 2011 00:37:39 +0000 Niall O'Reilly <Niall.oReilly <at> ucd.ie> 
wrote:

> 	SMTP has MX; others have SRV; HTTP is an outlier in that it
> 	avoids this kind of assistance from the DNS.  It's a significant
> 	and pathological outlier because of the way HTTPS works.

I'd look at it another way:
* SMTP has email forwarding (rewrite envelope TO)
* HTTP has 301 Permanent redirect.
* SIP has 3xx REFER (from memory)

All these make traffic to one place go to another. However in each
case in the 'S' variant of the protocol, you need to provide a separate
certificate for the alias to the canonical name, which means you
can't automatically configure / synthesise the alias config in
the same way you can for the non-'S' variant. What MX / SRV
are allowing you to do for services that support them is hide
this with another level of indirection.

For that indirection to be applied to http (e.g. use SRV records) you'd
need a change at the client end (to use SRV records or whatever) but also
at the server end, so if a.example.com = b.example.com, and both have SRV
records to c.example.com, then server c must use the cert for a or b as
appropriate. In https that's hard as the cert is chosen before the GET line
comes through. As solving this latter problem is enough to solve the entire
issue for https, I am not sure the SRV record thing helps if it works like
a normal SRV record.
(Continue reading)

Permalink | Reply | 32 comments |
headers
Stephane Bortzmeyer | 1 Mar 2011 10:49
Picon

Re: I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

On Mon, Feb 28, 2011 at 12:40:55PM -0500,
 Dan Schlitt <schlitt <at> world.std.com> wrote 
 a message of 38 lines which said:

> Weren't we told that we weren't dealing with "words" even though
> some things might look like words. This means that we don't have to
> deal with things like the difference between american english and
> british english.

In that case, it has to be said explicitely in the I-D (with
explanations of why english/american is less important than
simplified/traditional chinese).

But I understand the current draft as saying "We will not decide if
the difference between color.example and colour.example is significant
or not. We will just provide a neutral mechanism to make them 'the
same', should someone - typically the registry - decides they are the
same."  Am I correct in this reading of the I-D?

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
Permalink | Reply | 0 comments |
headers
Niall O'Reilly | 1 Mar 2011 11:25
Picon
Favicon

Re: I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt


On 1 Mar 2011, at 09:28, Alex Bligh wrote:

> For that indirection to be applied to http (e.g. use SRV records) you'd
> need a change at the client end (to use SRV records or whatever) but also
> at the server end, so if a.example.com = b.example.com, and both have SRV
> records to c.example.com, then server c must use the cert for a or b as
> appropriate.

	I'm thinking of a different way, which appears to avoid this problem.

	SRV maps a domain name (OK, a service,transport,name triple) to
	a (set of) host name(s).  If this mapping is provably legitimate
	(DNSSEC), then the browser need only verify that the cert matches
	the final host name.  Matching what I've chosen to call the
	'domain-part' of the http URL is no longer useful.  Used in this way,
	SRV gives us aggregation of certificates: one per target host rather
	than one per secure hosted web site.

	I may be missing something, but I think this needs only client-side
	code changes.  Service-side, certificate administration becomes
	different, but not code.

	ATB
	Niall

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
(Continue reading)

Permalink | Reply | 3 comments |
headers
Niall O'Reilly | 1 Mar 2011 11:27
Picon
Favicon

Re: I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt


On 1 Mar 2011, at 10:25, Niall O'Reilly wrote:

> 	code changes.  Service-side, certificate administration becomes

	Doh! s/Service/Server/
	N

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
Permalink | Reply | 0 comments |
headers
Alex Bligh | 1 Mar 2011 12:28
Picon

Re: I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt


--On 1 March 2011 10:25:45 +0000 Niall O'Reilly <Niall.oReilly <at> ucd.ie> 
wrote:

> 	SRV maps a domain name (OK, a service,transport,name triple) to
> 	a (set of) host name(s).  If this mapping is provably legitimate
> 	(DNSSEC), then the browser need only verify that the cert matches
> 	the final host name.  Matching what I've chosen to call the
> 	'domain-part' of the http URL is no longer useful.  Used in this way,
> 	SRV gives us aggregation of certificates: one per target host rather
> 	than one per secure hosted web site.
>
> 	I may be missing something, but I think this needs only client-side
> 	code changes.  Service-side, certificate administration becomes
> 	different, but not code.

So if a.example.com = b.example.com, and both have a SRV record to
c.example.com, then the client does an SRV lookup on (say) b.example.com,
receives the SRV record, then does an HTTP GET request to c.example.com
and (crucially) the GET line is
  GET http://c.example.com/
not
  GET http://b.example.com/
I believe that needs to be the case because the server needs to always
send back the same HTTP cert (as the decision in what cert to use is
prior to the GET line).

I'm a bit confused as to what you propose appears in the URL bar. IE
does the user know he's been redirected? Do local links on the
page appear as links from b.example.com or a.example.com?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Niall O'Reilly | 1 Mar 2011 13:36
Picon
Favicon

Re: I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

	I'm inclined to tease this out off-list, and spare the others
	the blow-by-blow.

On 1 Mar 2011, at 11:28, Alex Bligh wrote:

> So if a.example.com = b.example.com, and both have a SRV record to
> c.example.com, then the client does an SRV lookup on (say) b.example.com,
> receives the SRV record, then does an HTTP GET request to c.example.com
> and (crucially) the GET line is [...]
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
Permalink | Reply | 0 comments |
headers
Phillip Hallam-Baker | 1 Mar 2011 17:08
Picon

Re: I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

2011/2/27 Patrik Fältström <paf <at> cisco.com>:

> 2. Support of more application layer aliases
>
> 2.1. In HTTP and a few other protocols, we have the ability to do a redirect inside the application layer
protocol itself. We do not have that in all protocols. In other we have things like the MX records. Do we with
IDN etc need more of these, and do we need a mechanism in DNS that "help" such redirect in a "lower" layer in
the resolution algorithm?
>
> 2.2. When using HTTP HOST header, and SSL where the DN of the cert is matched with the domain name used, it is
kind of problematic to match the application layer with what originally was entered by the user. Is there
some need for DNS layer aliases that changes what later is matched in the application layer comparisons?

I would say not.

The legacy HTTP protocol requires that the name presented in the Host
header be the name that is present in the URL. There is no provision
for rewriting as far as I am aware.

Let us imagine we want a mapping a.com = b.com and the name a.com is
presented. There are two design choices:

1) The client performs the rewrite.

The best way to achieve this in my view would be to present a Host
header for b.com and add in a new header to tell the server that the
original origin was a.com

This is compatible with legacy servers but not legacy clients.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tony Finch | 3 Mar 2011 12:18
Picon
Favicon

Re: I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

On Tue, 1 Mar 2011, Alex Bligh wrote:
>
> However in each case in the 'S' variant of the protocol, you need to
> provide a separate certificate for the alias to the canonical name,
> which means you can't automatically configure / synthesise the alias
> config in the same way you can for the non-'S' variant. What MX / SRV
> are allowing you to do for services that support them is hide this with
> another level of indirection.

The situation with TLS and SMTP is a mess. Inter-domain SMTP with TLS does
not work with certificate validation. There is no specification for how to
validate the TLS certificate for an MX server, and it is not obvious what
such a specification should say. In practice the vast majority of deployed
MX TLS certificates cannot be validated, neither against the MX owner name
nor against the MX target.

http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

Message submission (RFC 4409) doesn't use MX records and works well with
certificate validation, just like POP and IMAP. Note that these three
protocols use the DNS in the same way as HTTP (and FTP, and telnet, and
ssh, etc.) so I don't think HTTP is an outlier as Niall said - it's just
old school.

> In https that's hard as the cert is chosen before the GET line comes
> through.

This is what TLS server name indication is for.

Tony.
(Continue reading)

Permalink | Reply | 27 comments |
headers
Mark Andrews | 3 Mar 2011 12:41

Re: I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt


In message <alpine.LSU.2.00.1103031107460.14985 <at> hermes-1.csi.cam.ac.uk>, Tony F
inch writes:
> On Tue, 1 Mar 2011, Alex Bligh wrote:
> >
> > However in each case in the 'S' variant of the protocol, you need to
> > provide a separate certificate for the alias to the canonical name,
> > which means you can't automatically configure / synthesise the alias
> > config in the same way you can for the non-'S' variant. What MX / SRV
> > are allowing you to do for services that support them is hide this with
> > another level of indirection.
> 
> The situation with TLS and SMTP is a mess. Inter-domain SMTP with TLS does
> not work with certificate validation. There is no specification for how to
> validate the TLS certificate for an MX server, and it is not obvious what
> such a specification should say. In practice the vast majority of deployed
> MX TLS certificates cannot be validated, neither against the MX owner name
> nor against the MX target.

If you read RFC 821 the HELO response should be used to check that
you are talking to the machine you are expecting to.

   3.5.  OPENING AND CLOSING

      At the time the transmission channel is opened there is an
      exchange to ensure that the hosts are communicating with the hosts
      they think they are.

      The following two commands are used in transmission channel
      opening and closing:
(Continue reading)

Permalink | Reply | 25 comments |

Gmane