Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 1 Mar 2015 10:21:33 -0500

On Sat, Feb 28, 2015 at 5:27 PM, Mark Andrews <[email-masked]> wrote:

>
> And that is coming "_25._tlsa" and it uses DNSSEC to prevent the
> downgrade.  Whether your MTA uses STARTTLS or not is another matter
> but we can prevent downgrade attacks from succeeding.
>

No it is not coming. The only way that can happen and be considered a
secure proposal is to charter a new working group in the security area to
work on a new security policy record to address the problem.

This is an important and difficult problem and one that the DANE working
group declared to be OUT OF SCOPE.

Every time I tried to raise the issues I was told they were OUT OF SCOPE.

As a result TLSA is a dogs breakfast. It is a combination of the key
publication mechanism the WG was chartered for and a security policy
mechanism that wasn't really chartered but was done anyway but only in a
half baked fashion.

This was my main concern with the DANE approach from the start. They would
refuse to consider the general problem. Deliver a product that creates more
problems than it solves when trying to solve the larger one and then insist
that we use it because it is 'a standard'.

Well DANE has practically no deployment or traction so I don't see it as a
fact on the ground that has to be worked on. This is a hard problem and it
is a problem that is easier to address from a clean sheet of paper than one
with a legacy support issue.

The way to address security policy for SRV type records is as follows:

1) Free the client end from the performance and data size issues imposed by
the legacy DNS client-resolver protocol.

DPRIV is a really good opportunity to tweak the protocol so we don't have
to worry about the client having to ask for multiple DNS RRs or that the
results might not fit into 500 bytes or an ethernet MTU.

2) Define a new security policy record that is designed to work with SRV
from the start and covers all the security policy concerns.

In particular make it possible to explicitly specify criteria such as 'use
TLS transport' or 'XYZ authentication is required'.

The first change is the more important one and the fix is quite easy.
Traditionally UDP DNS queries are one request packet and one response
packet. This ensures that the services are idempotent and the resolver does
not need to maintain TCP/IP connection state.

If we change the protocol so that a DNS request must still be a single
packet but a response can have multiple response packets we preserve the
connectionless, idempotent property while freeing ourselves from much of
the impact of the MTU size constraint.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 1 Mar 2015 20:27:27 +0000

On Sun, Mar 01, 2015 at 10:21:33AM -0500, Phillip Hallam-Baker wrote:

> > downgrade.  

Typo fix: that "_25._tlsa" is of course "_25._tcp".

> > Whether your MTA uses STARTTLS or not is another matter

If the MTA implements opportunistic DANE TLS, and usable TLSA
records *are* published, then it MUST use STARTTLS and authenticate
the peer via said TLSA records.

    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14#section-2.2

> TLS transport' or 'XYZ authentication is required'.

For both MX and SRV the DANE WG has settled on publication of TLSA
RRs to signal both "TLS is required" and "DANE authentication is
required".

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 02 Mar 2015 09:42:23 +1100

In message <[email-masked]>, Viktor Dukhovni write
> Typo fix: that "_25._tlsa" is of course "_25._tcp".

Thanks
 
>     http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14#section-2.2

I was refering to the fact that publishing records doesn't force
the client to use TLS as we have a large legacy population.  New
client will do this if they are not broken.  That said, adding explict
compliance tests to the rfc may not be a bad idea but this thread is
not the place to discuss it.  I wish EDNS had explict compliance tests
listed so we would not be in the mess we are in today.  Again this thread
is not the place to discuss this.

> RRs to signal both "TLS is required" and "DANE authentication is

Yep
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 1 Mar 2015 20:02:31 -0500

> RRs to signal both "TLS is required" and "DANE authentication is

I was actually referring to client authentication.

The DANE WG did make the decision you decide. But they did not get buy in
from any of the constituencies required to achieve deployment.

In standards work there is a big difference between describing *A* way to
do something and *THE* way to do something.

Sure there are folk who can move documents through IETF faster than a dose
of Ex-Lax will unblock a dodgy vindaloo. But the result is you end up with
a specification rather than a standard. Sometimes that is the desired
outcome.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 Feb 2015 13:39:47 -0500

>>>>> "Viktor" == Viktor Dukhovni <[email-masked]> writes:

    Viktor> On Fri, Feb 27, 2015 at 10:46:12AM -0600, Nico Williams wrote:
    >> I would much prefer a Standards-Track document that says to
    >> authenticate the origin domainname as follows:
    >> 
    >> - use DNSSEC for all DNS queries needed to find the URI RRs and
    >> DANE to authenticate the authorities of the resulting URIs
    >> 
    >> or
    >> 
    >> - expect the target authorities to have certificates that
    >> authenticate the origin, using SNI if need be.
    >> 
    >> I would still drop everything related to NAPTR and DDDS.

    Viktor> That works for me, and is in reasonable alignment with

I would object strongly to this because of the trust anchor reasons I've
discussed.
I think applicability advice discussing when it's appropriate to trust
DNS and how the DNS trust models differ from the TLS trust model are an
important consideration to standards-track work in this space.
It doesn't sound like Nico's document would include sufficient
discussion of that to make me happy.
I think that within the case where trusting DNS makes sense, Nico's
advice isn't the advice I'd give, but I wouldn't go so far as to object
to it.

I don't actually think TLSA adds much to this discussion.  If you're
willing to trust DNS and if you're using DNSSec, I don't see why you
can't just trust the target of the redirection.
What are you getting out of forcing DANE?

TLSA doesn't help the case where the app has stronger trust anchors
(within its trust domain) than the DNS trust anchors.

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 27 Feb 2015 20:50:28 +0100

> On 27 feb 2015, at 16:02, Andrew Newton <[email-masked]> wrote:
> 
> - I am also nervous over the size of the RRSet, i.e. same issue I see with NAPTR, and the reason why I added the prefix (like SRV) to the URI RR
> 
> I plan to move to use this advice. Thanks.

The encoding is important, I really like having multiple TXT strings (length-prefixed) but then "the last one" should be "the rest of RDATA"

Maybe Mark and others should think about how to do that encoding of the RDATA... I am lacking ideas here. Part from telling how many TXT strings there are.

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 27 Feb 2015 21:45:10 +0100

> On 27 feb 2015, at 21:37, Nico Williams <[email-masked]> wrote:
> 
> On Fri, Feb 27, 2015 at 08:07:25AM +0100, Patrik Fältström wrote:
>> My feedback to Andrew when he presented this to me was that:
>> 
>> - In general I am nervous of moving HTTP header attributes into the
>>  DNS, as it might create inconsistencies when for example the data in
>>  DNS do not match what is in the HTTP header, and we already have a
>>  content-negotiation mechanism in HTTP
> 
> If anything, it may not provide the optimization that's desired.  (Any
> numbers?)

Ok, to go back in history, this is why I originally did believe more in Gopher than Web... :-)

I though a proper negotiation would be to know already in the source of a referral what kind of data the target was. This was how Gopher worked, but Web was different. The link was (is) neutral and the negotiation happens at the target.

I did tell this to Tim, just like my view that HTML would have more TeX features like the ability to have "boxes" like various fills. He ignored me -- and I am happy for that!!!!

That story, early 1990's, gave me the lesson that the "correct" solutions do not always win. The "best" solution wins.

:-)

And this is the reason I am nervous over "gopher like features" in DNS. Even though I think it is good...I think it will loose...

   Patrik

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Mar 2015 15:52:00 +0000

On Fri, Feb 27, 2015 at 01:39:47PM -0500, Sam Hartman wrote:

> If you're willing to trust DNS and if you're using DNSSec, I don't see
> why you can't just trust the target of the redirection.

That's what one generally does.  Indeed TLSA records don't change
that part of the picture when trust in DNSSEC anchors makes sense.

> What are you getting out of forcing DANE?

I don't want to hijack this thread, so perhaps we can leave that
question for some future more appropriate context.

-- 
	Viktor.

---

From: Andrew Newton <[email-masked]>
Date: Mon, 2 Mar 2015 11:34:40 -0500

On Fri, Feb 27, 2015 at 4:00 PM, Nico Williams <[email-masked]>
wrote:

> > And this is the reason I am nervous over "gopher like features" in
> > DNS. Even though I think it is good...I think it will loose...
>
> I don't think that's a good enough reason here.  There may be other
> reasons to tread carefully here.
>

Agreed. Also, it seems the horse has already left the barn. With
application selection using prefixes, etc... that goes on with SRV,
S-NAPTR, and U-NAPTR (as well as URI), there is already "negotiation stuff"
in the DNS.

-andy

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Mar 2015 13:35:29 -0500

--On Sunday, March 01, 2015 20:27 +0000 Viktor Dukhovni
<[email-masked]> wrote:

>...
> records *are* published, then it MUST use STARTTLS and
> authenticate the peer via said TLSA records.
> 

Victor,

Please don't get too excited about statements like that, whether
they are written into I-Ds or not.  There are two separate
clusters of problems with it:

(1) Email, including SMTP, is based on a very old set of
protocols.  For reasons that are historical but still relevant
today, there is extensive deployment of the protocols in
embedded environments, many of them old enough that there has
been no option to upgrade them even to ESMTP and MIME, which are
now themselves over 20 years old.  Precisely because it works
well and is all but ubiquitous, email provides a communications
mechanism that has been plagued in recent years by spam,
phishing, and email-spread malware.  Those problems have brought
about operational changes and the "operational necessity" escape
clause in RFC 5321.  For other reasons, the mail system, almost
unique among IETF application protocols, is designed around a
hop by hop model, not an end to end one.  While that design was
originally important because of intermittently-connected
destinations and gateways to systems running other mail
protocols, it is now commercially vital for third-party
provisioning of enterprise mail systems (whether motivated by
antispam or other operational concerns).   As in the earlier
days, hop by hop models are difficult from a security standpoint
because the initiating client cannot be guaranteed to have the
ability to negotiate or handshake with the final destination
server.  It may be able to negotiate with an intermediate that
acts on the destination's behalf instead, but such negotiations
involve all of the difficulties with a trusted third party whose
identity and trustworthiness are hard to verify.

(2) The very essence of all, or almost all, mail-based phishing
attacks involves having someone accept a domain name, email
address, or URI as legitimate when it is actually not the
user-intended one.  Neither DNSSEC nor DANE prevent or detect
those attacks.  They may actually be harmful if they give the
user a false sense of security.  The main protections against
such attacks lie in user awareness, tools that identify or
highlight suspicious domain names or domains or addresses that
are known to be malicious, and a high degree of integrity by
registrars.  The latter has, at least IMO, proven to be a
failure.  In particular, when malicious parties can easily
register domains with misleading names, all DNSSEC does is to
verify that the DNS records were not altered in transit and DANE
is as happy to provide key material associated with a malicious
domain as a desirable one.

    john

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Mar 2015 18:44:59 +0000

> > http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14#section-2.2

[ Well known details elided. ]

> Neither DNSSEC nor DANE prevent or detect
> user a false sense of security.

Since the user is not around for MTA-to-MTA SMTP transmission there
is no opportunity for any false sense of security.  So I object to
a characterization of improved hop by hop transport security as
"harmful".  This is not the thread to deep dive into that.

-- 
	Viktor.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 2 Mar 2015 22:47:38 +0100

> On 2 mar 2015, at 17:34, Andrew Newton <[email-masked]> wrote:
> 
> On Fri, Feb 27, 2015 at 4:00 PM, Nico Williams <[email-masked] <mailto:[email-masked]>> wrote:
> Agreed. Also, it seems the horse has already left the barn. With application selection using prefixes, etc... that goes on with SRV, S-NAPTR, and U-NAPTR (as well as URI), there is already "negotiation stuff" in the DNS.

I agree with that but I differ between the "service selection" which I think the prefix is, and the "content negotiation" which is happening as part of HTTP. I do not really see in HTTP a negotiation between SMTP, IMAP and WEB, although with websockets we probably will ;-)

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Mar 2015 11:51:57 +1100

In message <[email-masked]>, =?utf-8?Q?Patrik_F
=C3=A4ltstr=C3=B6m?= writes:
> > - I am also nervous over the size of the RRSet, i.e. same issue I see
> with NAPTR, and the reason why I added the prefix (like SRV) to the URI RR
> >
> The encoding is important, I really like having multiple TXT strings
> (length-prefixed) but then "the last one" should be "the rest of RDATA"
>
> Maybe Mark and others should think about how to do that encoding of the
> RDATA... I am lacking ideas here. Part from telling how many TXT strings
> there are.
>
>    paf

I don't really care about the encoding as long as it is *stable*.

The wire format has gone from a series of <len><value> pairs that
get concatenated for use (up to draft-faltstrom-uri-07) to just
<value> with a implict length (draft-faltstrom-uri-08).  The type
code was allocated against draft-faltstrom-uri-05.

Below are some of the tradeoffs that result from the different wire
encodings.

Master files need to preserve wire encoding (for DNSSEC) so
<len><value> pairs restrict how master files are written.  This
leads to lines which are potentially over a 1000 bytes long due to
\DDD encodings of non-ascii.

With a plain <value> and concatenation you don't have to have long
lines in master files and you can print the field out over multiple
lines knowing you can recombine the field.

example.net. 	URI ( 0 1 "http://foo.bar/"
		      "xxx?lhllshdflldhlh;"
		      "yyy?lhjjgjfkakfjkfjak" )

Mark

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Mar 2015 10:41:10 +1100

Hi Pete,

The example still uses a Web home page, even though this use of the URI record isn't specified nor used by any implementation I'm aware of (and even if there were one, it wouldn't be interoperable).

Changing to another example would fix this. 

Cheers,

> On 5 Mar 2015, at 9:25 am, Pete Resnick <[email-masked]> wrote:
> 
> [Explicitly Cc'ing folks who participated in the thread.]
> 
> On 2/27/15 10:24 AM, Pete Resnick wrote:
>> I'm going to ask Patrik to publish a revised ID at this point, which I expect to see in the next couple of days.
> 
> The new version of the document (-12) is out, announcement attached. It is now Informational, it removes the discussion of flag "D" for NAPTR, and adds a bit of discussion to security considerations. I would appreciate folks giving it a sniff and making sure it addresses your earlier concerns. If so, I'll go ahead and ballot it for the 12-March IESG telechat.
> 
> Thanks,
> 
> pr
> 
> -- 
> Pete Resnick<http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
> 

Subject: New Version Notification - draft-faltstrom-uri-12.txt
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Paul E. Hoffman" <[email-masked]>, <[email-masked]>
Date: Wed, 4 Mar 2015 13:55:19 -0800

A new version (-12) has been submitted for draft-faltstrom-uri:
http://www.ietf.org/internet-drafts/draft-faltstrom-uri-12.txt

Sub state has been changed to AD Followup from Revised ID Needed

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-faltstrom-uri/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-faltstrom-uri-12

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.

IETF Secretariat.

--
Mark Nottingham   https://www.mnot.net/

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 5 Mar 2015 06:29:20 +0100

All, specifically Mark,

This was a stupid editorial mistake by myself. It should have been replaced. So much for merging documents when being too tired 23:00 in the evening on the day the AD had given me a deadline... My apologies.

Pete, please let me know when you want a new version, -13.txt

   Patrik

> On 5 mar 2015, at 00:41, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Pete,
> 
> <Attached Message.eml>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Mar 2015 16:31:46 +1100

Been there - no worries, and thanks.

Cheers,

> On 5 Mar 2015, at 4:29 pm, Patrik Fältström <[email-masked]> wrote:
> 
> All, specifically Mark,
>

---

From: Pete Resnick <[email-masked]>
Date: Wed, 4 Mar 2015 23:38:18 -0600

paf:

At least post here your suggested replacement text. Assuming Mark (and 
others) are on board with it, we can put it in an RFC Editor for the 
time being and roll a new version after IESG Eval.

pr

On 3/4/15 11:29 PM, Patrik Fältström wrote:
>> On 5 mar 2015, at 00:41, Mark Nottingham<[email-masked]>  wrote:
>>
>> Hi Pete,
>>
>>> On 5 Mar 2015, at 9:25 am, Pete Resnick<[email-masked]>  wrote:
>>>

---

From: Pete Resnick <[email-masked]>
Date: Thu, 5 Mar 2015 00:51:07 -0600

A specific text suggestion (even better if you and Sam were to agree on 
it) would be greatly appreciated.

pr

On 3/5/15 12:45 AM, Viktor Dukhovni wrote:
> On Wed, Mar 04, 2015 at 04:25:20PM -0600, Pete Resnick wrote:
>
>    
>>> I'm going to ask Patrik to publish a revised ID at this point, which I
>>> expect to see in the next couple of days.
>>>        
>> The new version of the document (-12) is out, announcement attached. It is
>> now Informational, it removes the discussion of flag "D" for NAPTR, and adds
>> a bit of discussion to security considerations. I would appreciate folks
>> giving it a sniff and making sure it addresses your earlier concerns. If so,
>> I'll go ahead and ballot it for the 12-March IESG telechat.
>>      
> I think this still fails to acknowledge Sam Hartman's concerns
> about the change in the security model from (often with TLS)
> application configured trust anchors that may be specific to the
> expected peer, to likely the ICANN DNSSEC root trust-anchor, or
> perhaps an enterprise DNS trust-anchor for an internal domain.
>
> While such a change in the trust model may well be applicable,
> there remains in the draft a claim that indirection through DNSSEC
> is fundamentally not different from indirection through a TLS
> authenticated HTTP redirect.  That claim is likely too bold.  Future
> users of this RR need to consider the issues more carefully.
>
> * DNSSEC is often stronger than today's Web PKI DV certs.
>
> * However, with the traditional PKI it is far easier to
>    not trust any of the usual suspects and built direct
>    peer to peer trust.
>
> * With DNSSEC the most specific one can be is in some cases have
>    a local trust-anchor for the zone apex of the service domain,
>    ( I'm involved in an internal DNSSEC deployment with some secure
>    internal zones with explicit local trust-anchor settings. )
>
> * More broadly however there's just the ICANN root, and perhaps
>    some day the ability to use RFC 5011 to track zsk rollovers
>    of any TLDs that commit to implement the requisite key management
>    discipline.  Going beyond that to bilateral trust-anchors between
>    business partner organizations is rather exotic.
>
> * All the while various non-browser B2B applications employ explicit
>    destination-specific trust-anchors that perhaps should not be
>    subordinate to the ICANN root or gTLDs.
>
> So various problem spaces are better served by the Web PKI, DNSSEC
> PKI or just bilaterally managed trust anchors, and these are not
> simply interchangeable.
>
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Mar 2015 07:14:09 +0000

On Thu, Mar 05, 2015 at 07:56:09AM +0100, Eliot Lear wrote:
> Victor,
> 
> A simple way to address the concern that Sam raised is to note that
> DNSSEC's trust model is largely binary, and not subject to alternative
> trust anchors.  That is- parent zone administrator's keys may either be
> trusted or not.  On the other hand, I don't know that this is the draft
> to take on that issue.  It's a fundamental difference between the two
> models and there are pluses and minuses to each, and it's perhaps worth
> exploring, but in this draft?

I don't see a need to explore the details in this draft, rather it
just needs to avoid claiming equivalence.  Just don't pretend the
issue is not there.  

So for me it would be enough to note that DNSSEC introduces a new
trust model than application designers need to consider when the
URI DNS record is introduced into application designs.

If that's good enough for Sam too, then perhaps he or I can write
a sentence or two saying essentially that to replace the IMHO overly
strong claim that DNSSEC indirection is essentially the same as
HTTP redirects.

-- 
	Viktor.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 5 Mar 2015 08:49:26 +0100

> On 5 mar 2015, at 06:38, Pete Resnick <[email-masked]> wrote:
> 
> paf:
> 
> At least post here your suggested replacement text. Assuming Mark (and others) are on board with it, we can put it in an RFC Editor for the time being and roll a new version after IESG Eval.

Here:

5.1.  Example: FTP server in the example.com domain

   An organisation has the domain names example.com and example.net, and
   their FTP archive is at ftp://ftp1.example.com/public.  Given the
   Service Name "ftp" and Transport Protocol "tcp" (from the IANA
   registry of Service Name and Transport Protocol Port Numbers), the
   following URI Resource Records could be made available in the
   respective zones (example.com and example.net):

   $ORIGIN example.com.
   _ftp._tcp    IN URI 10 1 "ftp://ftp1.example.com/public"

   $ORIGIN example.net.
   _ftp._tcp    IN URI 10 1 "ftp://ftp1.example.com/public"

I would like to get an example from the Kerberos discussions, but I need help from Nico Williams for that.

   Patrik

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 Mar 2015 09:32:29 -0500

Viktor> On Wed, Mar 04, 2015 at 04:25:20PM -0600, Pete Resnick wrote:
    >> >I'm going to ask Patrik to publish a revised ID at this point,
    >> which I >expect to see in the next couple of days.
    >> 
    >> The new version of the document (-12) is out, announcement
    >> attached. It is now Informational, it removes the discussion of
    >> flag "D" for NAPTR, and adds a bit of discussion to security
    >> considerations. I would appreciate folks giving it a sniff and
    >> making sure it addresses your earlier concerns. If so, I'll go
    >> ahead and ballot it for the 12-March IESG telechat.

    Viktor> I think this still fails to acknowledge Sam Hartman's
    Viktor> concerns about the change in the security model from (often
    Viktor> with TLS) application configured trust anchors that may be
    Viktor> specific to the expected peer, to likely the ICANN DNSSEC
    Viktor> root trust-anchor, or perhaps an enterprise DNS trust-anchor
    Viktor> for an internal domain.

    Viktor> While such a change in the trust model may well be
    Viktor> applicable, there remains in the draft a claim that
    Viktor> indirection through DNSSEC is fundamentally not different
    Viktor> from indirection through a TLS authenticated HTTP redirect.
    Viktor> That claim is likely too bold.  Future users of this RR need
    Viktor> to consider the issues more carefully.

The claim in the draft is:
>   comparison, and that the change in what hostname to use is secured by
>   DNSSEC so that it can be trusted in a similar way as a redirect in
>   HTTP using TLS.

I'm actually OK with that claim in an informational RFC because of the
word similarly.
I think the current version is good enough for informational.
I think Eliot's proposal 

>trusted or not.  

would improve the text, but I'm OK with the draft as-is.
Thanks for diligent work resolving raised concerns.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Mar 2015 06:45:13 +0000

-- 
	Viktor.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 05 Mar 2015 07:56:09 +0100

Victor,

Eliot

---

From: Pete Resnick <[email-masked]>
Date: Wed, 4 Mar 2015 16:25:20 -0600

> expect to see in the next couple of days.

The new version of the document (-12) is out, announcement attached. It 
is now Informational, it removes the discussion of flag "D" for NAPTR, 
and adds a bit of discussion to security considerations. I would 
appreciate folks giving it a sniff and making sure it addresses your 
earlier concerns. If so, I'll go ahead and ballot it for the 12-March 
IESG telechat.

Thanks,

pr

IETF Secretariat.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Mar 2015 09:05:06 +0000

On Fri, Mar 06, 2015 at 02:28:44AM -0500, John C Klensin wrote:

> That said, if the IETF considers it to be a valid implementation
> of DNSSEC to have the closest-to-user validating system be an
> ISP-based forwarder rather than a machine on the user's LAN,
> there isn't a lot of point in building DNSSEC capability into
> zeroconf stuff that is mostly applicable intra-LAN or otherwise
> within a trust perimeter that the DNSSEC validator is outside of.

Where did this notion come from?  I've seen no documents that
suggest this.  On the contrary, there is even some push back to
using a security-aware non-validating stub resolver that chains to
a trusted loopback-net validating cache.  *Trusting* the ISP's
validating resolver is indeed pointless and I've not seen anyone
suggest this.

If grandma had wheels, she'd be a wagon.

Of course once can still *use* an ISP's validating resolver as an
untrusted cache, with or without "CD" as appropriate.

> Put differently, any time a DNSSEC-based trust model comes down
> to "trust your ISP", then it is pointless overhead for any of us
> who already know our ISPs can't be trusted.  And _that_ is why
> I'm reluctant to see it oversold in circumstances like the
> current document.

In any case nobody's suggesting over-selling DNSSEC here, all the
suggested changes have been about the claims for DNSSEC being
originally too strong.

Nevertheless if a URI RR is to be trusted to change the authenticated
authority (RFC6125 reference identifier), then one should at least
do DNSSEC or else (when DNSSEC is not fit for purpose) not change
the authority (and fail authentication when the target's certificate
fails to match the original domain).  In the latter case complications
may arise with SNI (which domain goes in the client's SNI extension
and may it differ from the HTTP request Host: header?).

All the document has to do is avoid claiming that trusting DNSSEC
is *equivalent* to trusting the application's "usual" PKIX
trust-anchors (whatever they might be).  Sometimes DNSSEC is worse,
sometimes it is better.  It should also caution against accepting
completely unauthenticated redirection, so given that the redirection
is via DNS you either use DNSSEC or don't trust the redirection
choose one.

Nothing controversial, just basic tautologies that may not be
obvious to all.

-- 
	Viktor.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 Mar 2015 11:36:12 -0500

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> If anything, the text now says too much because introductory
    John> statements like "The basic mechanism for successful use of URI
    John> works..." strongly imply that use of, and reliance on, DNSSEC
    John> is the only way to accomplish successful (and safe) use.  The
    John> current Security Considerations section could be equated to an
    John> Applicability Statement that said "unless DNSSEC is used, and
    John> used as specified in this document, use of the URI RR is NOT
    John> RECOMMENDED".  I don't think that is either intended or
    John> justified.

I do think an applicability statement that says this RR is inappropriate
for situations where authentication of the accessed resource is desired
and DNSSec is not used.  I think that's justified and hoped something
like that was intended by section 7.
I agree that there are uses where you don't care about the
authentication of the accessed resource where DNSSec is not required.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 06 Mar 2015 08:56:05 -0500

I think that the security considerations in -10 are better than what we
seem to be wordsmithing on the list.
My preference is to call -10 good enough in this regard especially given
that it is informational.

I don't support  a desire to reduce the strength of security warnings in
the document, as I think John may be asking for.
However personally I don' have the energy to really engage in much more
of a discussion for this document.

I think AS work is quite important,  and I hope that happens at a time
when I have energy to participate but it's far more important to me that
it happen regardless of my participation.

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Mar 2015 11:25:19 -0500

(heads-up to readers -- there are a couple of issues identified
below that are separate from the security ones)

--On Thursday, March 05, 2015 07:56 +0100 Eliot Lear
<[email-masked]> wrote:

> A simple way to address the concern that Sam raised is to note
> that DNSSEC's trust model is largely binary, and not subject
> to alternative trust anchors.  That is- parent zone
> administrator's keys may either be trusted or not.  On the
> other hand, I don't know that this is the draft to take on
> that issue.  It's a fundamental difference between the two
> models and there are pluses and minuses to each, and it's
> perhaps worth exploring, but in this draft?

Eliot's comment above is consistent with my prior remarks on the
subject (including at least one off-list and a few others I was
too fed up to send).    I think this issue is a real and
important one.  I think some documentation about what DNSSEC
(and, by the way, DANE, etc.) are useful and/or optimal for (and
what their trust model implications and assumptions are) is
definitely needed.  But the issues are neither new nor unique to
this spec or RRTYPE.  IMO, _at most_, this document should
contain a statement indicating that there are issues and that
applications considering using this RRTYPE should be aware of
them.

If anything, the text now says too much because introductory
statements like "The basic mechanism for successful use of URI
works..." strongly imply that use of, and reliance on, DNSSEC is
the only way to accomplish successful (and safe) use.  The
current Security Considerations section could be equated to an
Applicability Statement that said "unless DNSSEC is used, and
used as specified in this document, use of the URI RR is NOT
RECOMMENDED".  I don't think that is either intended or
justified.

On a separate topic, I'm not sure that the second paragraph of
the Introduction is correct.  Historically (sic) and as far as I
am aware, DDDS has been used heavily only in conjunction with
ENUM.  It also takes me three or four readings each time I
encounter it to figure out what "looking up URIs given a
hostname" means (noting that, for some versions of DNS
terminology, a hypothetical domain (owner, node) with only NAPTR
records is _not_ a "hostname").  Perhaps something more like the
following would be both more true and easier to understand:

	Historically, uses of the DNS to map a domain name to a
	URL have relied on the NAPTR RRTYPEs and then on the
	DDDS[RFC3401] application framework with the DNS as a
	database as specified in RFC 3404 [RFC3404].

The following sentence isn't clear, which doesn't help.
Probably what is intended more like:

	Among the implications of that usage are inability to
	select interesting and relevant NAPTR records from those
	that match the query.

There are several other editorial issues (e.g., "Querying for
URI resource records is not replacing querying..." later in the
Introduction and "Applications MUST know the specific service to
prepend..." in Section 3 (one cannot prepend "a service", only
an identifier of one)), but I hope we can leave them to the RFC
Editor to identify and sort out.

Otherwise, I believe my concerns have been addressed.

Finally, given these discussions, I believe the Acknowledgements
section probably needs review and updating.

best,
    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Mar 2015 15:59:40 -0500

--On Thursday, March 05, 2015 20:12 +0100 Patrik Fältström
<[email-masked]> wrote:

> Thanks.
> What about:
>    Historically, uses of the DNS to map a domain name to a URL
> have    relied on the NAPTR RRTYPEs and then on the DDDS
> [RFC3401]    application framework with the DNS as a database
> as specified in RFC    3404 [RFC3404].  This has a number of
> implications such as the fact    the RRSet returned will
> contain all URIs "connected" with the owner,    and not only
> the ones related to a specific service.

If _that_ is what you meant, I've been very confused... and the
above is a huge improvement.

>> URI resource records is not replacing querying..." later in
>> the Introduction and "Applications MUST know the specific
>> service to prepend..." in Section 3 (one cannot prepend "a
>> service", only an identifier of one)), but I hope we can
>> leave them to the RFC Editor to identify and sort out.
> 
> Yeah, as you know John, my english is not the best... :-(

As I have said many times before, lots better than my Swedish.
That is why we have an RFC Editor.  It does mean that you should
keep an eye on them at AUTH48 and/or ask for a little help from
your friends :-).  

>> Finally, given these discussions, I believe the
>> Acknowledgements section probably needs review and updating.
> 
> Now:

Good enough.  I wasn't looking for anything in particular, just
noting that the document has changed a lot in the last couple of
weeks and that section had not been updated to match.

    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Mar 2015 01:14:51 -0500

--On Thursday, March 05, 2015 20:01 +0100 Patrik Fältström
<[email-masked]> wrote:

> What about something like this:
> 
> 7.  Security Considerations
> 
>    DNS is a protocol both running over UDP and TCP, it also
> explicitly    uses proxies, for clients in many cases

Given that the term "proxy" does not appear in either 1034 or
1035 and is sometimes use to refer to something that intercepts
and changes DNS responses (exactly what DNSSEC is suppose to
prevent) I think you should either choose a different term or
provide a definition or reference.  Certainly "explicitly uses
proxies" is incorrect without such qualification.

> configured using DHCP.  An    extension to DNS has been
> developed called DNSSEC that give the    ability for the
> receiver of a response to a DNS query to validate an
> electronic signature.  With a proper validation the content
> can be    trusted to a much higher degree.

See my prior whine about trust models.  I think you should be
talking about an integrity check (on consistency between what is
stored in the DNS and the query response) here and not hand-wave
about "validation" or degrees of trust.  DNSSEC can be said to
verify that the records received at an endpoint )or the last
validation point) are consistent with what is stored under the
name for which the query was actually issued.  If should not
enhance the trust that the name that the user intended actually
reached a server.  Even if one ignores deliberate phishing, as
you know better than most, trust assertions about whether what
the user intended and what a server sees get very tricky when,
e.g., something like UTR 46 modifies the labels being looked up
before IDNA or query processing.

> One description of
> a threat model    to DNS, including description of what
> threats DNSSEC is intended to    defend against can be found
> in RFC 3833 [RFC3833].
> 
>    If for example the URI resource record is not signed with
> the help of    DNSSEC and validated successfully, trusting the
> non-signed URI might    lead to a downgrade attack.

While this may be obvious to experts, the experts probably don't
need it.  For everyone else, you are probably missing a
statement about interception, changes to the query or URI, and a
system that won't respond as intended to STARTTLS or equivalent.
Note, in particular, that if one started out with:

  foo.example.com. IN URI 0 0  good.example.com.

and a query for that produced a response that contained
  foo.example.com. IN URI 0 0  evil.example.com.

That would clearly be a problem for DNSSEC but, if both of the
hosts designated by "good" and "evil" responded to STAETTLS by
opening TLS connections at desired degrees of security, there
would be no downgrade attack, "only" a MITM host diversion
attack.

>    What also can happen is that the URI in the resource record
> type has    errors in it.  Applications using the URI resource
> record type for    resolution should behave similarly as if
> the user typed (or copy and    pasted) the URI.  At least it
> must be clear to the user that the    error is not due to any
> error from his side.
 
>    One SHOULD NOT include userinfo (see User Information,
> Section 3.2.1,    in RFC 3986 [RFC3986]) in a URI that is used
> in a URI resource record    as DNS data must be viewed as
> publicly available information.

Generally, while I think you should warn that URI records may
cause some risks that do not exist with, e.g., conventional name
to address mappings (note that the "downgrade attack or not"
considerations above would apply equally well to:

  foo.example.com.  IN A 10.2.0.44
being diverted into a response of 
  foo.example.com.  IN A 10.0.0.6

(which would be, historically, a likely upgrade attack, but it
has nothing to do with URI records but is equally preventable by
an integrity check.))

As long as there is a warning, I really don't care very much
what you say, but whatever you do say should be as accurate as
possible.

   john

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Mar 2015 02:28:44 -0500

--On Friday, March 06, 2015 07:28 +0100 Patrik Fältström
<[email-masked]> wrote:

> Thanks for the comments. While digesting them, I have one
> comment:
> 
>> On 6 mar 2015, at 07:14, John C Klensin <[email-masked]>
>> wrote:
>> 
>> cause some risks that do not exist with, e.g., conventional
>> name to address mappings (note that the "downgrade attack or
>> not" considerations above would apply equally well to:
>> 
>> has nothing to do with URI records but is equally preventable
>> by an integrity check.))
>> 
> I also see tons of zeroconf stuff (Apple Bonjour) using DNS
> already today in the geographically local context without much
> DNSSEC.

I think that strengthens the argument for some Applicability
Statement action about DNS-related threats, trust models, and
attacks that integrity checks do or do not protect against
rather than trying to push too much off on this particular
document.  I still don't have a strong opinion about where the
optimal boundaries lies, but I don't think it is rational for
the IETF to not do the A/S work but then hold up individual
documents because they don't contain all of the discussion that
A/S might contain.

    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Mar 2015 09:12:10 -0500

--On Friday, March 06, 2015 08:56 -0500 Sam Hartman
<[email-masked]> wrote:

> I think that the security considerations in -10 are better
> than what we seem to be wordsmithing on the list.
> My preference is to call -10 good enough in this regard
> especially given that it is informational.
> 
> I don't support  a desire to reduce the strength of security
> warnings in the document, as I think John may be asking for.

No, I'm not.  I think they are fine.  I just see diminishing
returns in further holding the document up for fine tuning.  And
I essentially agree with the part of Viktor's recent comments
that I interpret as saying "good enough".

> However personally I don' have the energy to really engage in
> much more of a discussion for this document.
> 
> I think AS work is quite important,  and I hope that happens
> at a time when I have energy to participate but it's far more
> important to me that it happen regardless of my participation.

Me too.  For both of us.

    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Mar 2015 10:22:25 -0500

--On Friday, March 06, 2015 12:51 +0100 Eliot Lear
<[email-masked]> wrote:

> I just wanted to say that I think it's a bad idea to make this
> thing informational.  The fact is that URI has been kicking
> around for years upon years, and what we are doing now is
> documenting existing practice.  PS is a perfectly fine
> instrument to gain experience, warts and all, with URI.

Eliot,

The counterargument is that we've gotten into a trap.  In
theory, PS implies something that we can use, as you say, to
gain experience, etc.  But that experience is useless unless the
IETF has practical change control and can make alterations
dictated by community review (before PS approval or after that
experience accumulates).

Because this RRTYPE is already registered and the registration
cannot be changed in an incompatible way, that condition doesn't
apply -- any experience we gain could only be used to inform an
Applicability Statement that might say "don't use this" or "use
this only if if series of other conditions have been met".  Such
an Applicability Statement (or nearly-equivalent BCP) could
perfectly well be issued against an Informational document.

The various Last Call design reviews have identified several
changes that people would like to make to the RRTYPE itself (I
am not claiming consensus for any of them because they haven't
been discussed sufficiently).  However, this cannot be a normal
Last Call for a normal would-be PS spec, because those changes
[1] cannot be considered and, if appropriate, made.

I think this "register by Expert Review, freeze technical
content, and then discuss standardization" path is a problem,
potentially a serious one, for the IETF.  But I think the place
to sort it out is in our norms for Expert Review leading to
registrations, e.g., in draft-leiba-cotton-iana-5226bis or in
changes to the (IIR, unwritten) "IETF has change control" and
the very explicit "known defects" rule in 2026.  Until and
unless such changes occur, I just don't see a way to put this on
the standards track that does not result in worse problems.

best,
    john

[1] While most of the focus of the discussions has been on
security, there are some other substantive issues too.  For
example, (i) given that this RRTYPE moves the service being
requested from the RDATA to the Owner of the DNS entry, is
"Weight" still justified and is it likely to cause more trouble
than it is worth or (ii) given recent controversies about kinds
and uses of URIs, including the debate about how much different
URNs should be from URLs and generic (but presumably
location-oriented) URIs, should there be restrictions on the
type and/or content of URIs that are considered appropriate for
use with the RRTYPE?    The issue isn't what the answer to those
question should it; it is that they can't really be asked.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Mar 2015 12:51:25 +0100

Hi Pete,

On 3/4/15 11:25 PM, Pete Resnick wrote:
>> I'm going to ask Patrik to publish a revised ID at this point, which
>> I expect to see in the next couple of days.
>
> The new version of the document (-12) is out, announcement attached.
> It is now Informational, it removes the discussion of flag "D" for
> NAPTR, and adds a bit of discussion to security considerations. I
> would appreciate folks giving it a sniff and making sure it addresses
> your earlier concerns. If so, I'll go ahead and ballot it for the
> 12-March IESG telechat.

I just wanted to say that I think it's a bad idea to make this thing
informational.  The fact is that URI has been kicking around for years
upon years, and what we are doing now is documenting existing practice. 
PS is a perfectly fine instrument to gain experience, warts and all,
with URI.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 06 Mar 2015 16:52:56 +0100

I would agree that on the whole we want people to register RR types
through the standardization process.  However, if someone actually
followed our process, as Patrik did, and defined the RR type and
documented it, and then this document sat around for eight years, as it
did, I don't think it's reasonable to hold Patrik accountable for that,
and I think it discourages others from bringing work to the IETF.

---

From: Nico Williams <[email-masked]>
Date: Fri, 6 Mar 2015 09:05:34 -0600

That's mDNS, which is not the DNS, just an insecure local discovery
protocol based on DNS wire messages.  Surely mDNS is out of odd scope here.

Nico

On Friday, March 6, 2015, John C Klensin <[email-masked]> wrote:

> <[email-masked] <javascript:;>> wrote:
>
> >> On 6 mar 2015, at 07:14, John C Klensin <[email-masked]
> <javascript:;>>
> >> wrote:
> >>

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 5 Mar 2015 20:01:56 +0100

> On 5 mar 2015, at 17:36, Sam Hartman <[email-masked]> wrote:
> 

I am reading what is said in this thread, and will try to come up with a security considerations section that explain the issues, but it must ultimately be up to whoever is using it to decide how to apply the policy. I do not feel comfortable having this document start go down the path of saying whether security mechanism A is better than B, if C is good enough for the Internet or such.

   DNS is a protocol both running over UDP and TCP, it also explicitly
   uses proxies, for clients in many cases configured using DHCP.  An
   extension to DNS has been developed called DNSSEC that give the
   ability for the receiver of a response to a DNS query to validate an
   electronic signature.  With a proper validation the content can be
   trusted to a much higher degree.  One description of a threat model
   to DNS, including description of what threats DNSSEC is intended to
   defend against can be found in RFC 3833 [RFC3833].

   If for example the URI resource record is not signed with the help of
   DNSSEC and validated successfully, trusting the non-signed URI might
   lead to a downgrade attack.

   What also can happen is that the URI in the resource record type has
   errors in it.  Applications using the URI resource record type for
   resolution should behave similarly as if the user typed (or copy and
   pasted) the URI.  At least it must be clear to the user that the
   error is not due to any error from his side.

   One SHOULD NOT include userinfo (see User Information, Section 3.2.1,
   in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record
   as DNS data must be viewed as publicly available information.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 5 Mar 2015 20:12:42 +0100

> On 5 mar 2015, at 17:25, John C Klensin <[email-masked]> wrote:
> 

Thanks.

What about:

   Historically, uses of the DNS to map a domain name to a URL have
   relied on the NAPTR RRTYPEs and then on the DDDS [RFC3401]
   application framework with the DNS as a database as specified in RFC
   3404 [RFC3404].  This has a number of implications such as the fact
   the RRSet returned will contain all URIs "connected" with the owner,
   and not only the ones related to a specific service.

Now:

8.  Acknowledgements

   Ideas on how to split the two different kind of queries "What
   services exists for this domain name" and "What is the URI for this
   service" came from Scott Bradner and Lawrence Conroy.  Other people
   that have contributed to this document include Richard Barnes, Leslie
   Daigle, Victor Dukhovni, Olafur Gudmundsson, Philip Hallam-Baker, Ted
   Hardie, Sam Hartman, Evan Hunt, John klensin, Peter Koch, Eliot Lear,
   Andy Newton, Mark Nottingham, Penn Pfautz, Jinmei Tatuya, Willem
   Toorop, Nico Williams.

My apologies if I am still missing people. Please let me know if you should be added (or if you think someone should be added).

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 6 Mar 2015 07:28:55 +0100

Thanks for the comments. While digesting them, I have one comment:

> On 6 mar 2015, at 07:14, John C Klensin <[email-masked]> wrote:
> 

I also see tons of zeroconf stuff (Apple Bonjour) using DNS already today in the geographically local context without much DNSSEC.

   Patrik

---

From: Pete Resnick <[email-masked]>
Date: Fri, 6 Mar 2015 11:41:23 -0600

Closing the loop:

>> important to me that it happen regardless of my participation.

I just confirmed with Sam that of course he meant -12, not -10. So my 
conclusion is that we are going with -12, as an Informational RFC, with 
the one change being the change in example from Web to FTP.

Thanks to you all for helping drive this to completion.

> and I think it discourages others from bringing work to the IETF.

There is a much longer discussion to be had on this topic than I'm 
willing to do here, but summarized: This experience puts an exclamation 
point on the thought that I've had for some time, that AD-sponsored 
documents, and doing things outside of the context of a WG generally, is 
a really bad idea if you want something standardized in the IETF. The 
reason that people have been doing so (whether consciously or just 
influenced to do so) is that the WG process and coming to consensus 
seemed (and truly was) hugely daunting. But we end up in situations like 
this, where things get developed without the iterative 
consensus-building that we're supposed to be doing. The better thing to 
do in order to not discourage others and to create good work is to 
improve the speed at which WGs get things done and make it less 
daunting, and I believe that we've been doing that of late: We've had 
several good examples of WGs that we've spun on quickly to do a focused 
piece of work, and they're done in months, not years. But more beer 
required to fully have that discussion.

pr

---

From: Pete Resnick <[email-masked]>
Date: Fri, 6 Mar 2015 11:44:45 -0600

On 3/6/15 11:41 AM, Pete Resnick wrote:
> So my conclusion is that we are going with -12, as an Informational 
> RFC, with the one change being the change in example from Web to FTP.

Oh! Forgot: And the change to the second paragraph in the Intro.

> Thanks to you all for helping drive this to completion. 

Again.

pr

---

From: t.p. <[email-masked]>
Date: Sat, 7 Mar 2015 12:06:04 +0000

----- Original Message -----
From: "Pete Resnick" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Sent: Friday, March 06, 2015 5:41 PM
> Closing the loop:
<snip>
> required to fully have that discussion.

Pete

I agree and find it timely.  I have been noting the tide of I-D with
YANG models being posted and particularly those with names such as
draft-johndoe-netmod-routing-apps-etc
The format of the I-D's name implies, to most of us, that this I-D is
headed for the netmod WG which I think is unlikely to produce a
satisfactory RFC on the topic.  Whatever the technology to be managed
is, I think that the prime requirement is to have those expert in the
technology work on it first, producing something at the level of an
Information Model.  Get that wrong and you may have a perfect, but
useless, management module, regardless of whether it is in YANG, SNMP,
etc.

I note that one such I-D started out
draft-zhdankin-netmod-bgp-cfg-01
and became
draft-zhdankin-idr-bgp-cfg-01
Spot on, but it could have been right from the word go.

Fine when there is an obvious WG, but what to do when there is not?
Where should
draft-asechoud-netmod-diffserv-model-01.txt
go?  I suspect that the netmod WG has few diffserv skills, but where in
the IETF are there any?  Not enough to form a WG I suspect.  This is the
sort of thing that becomes AD-sponsored but I think that it should not.
Informational?  Or should the IETF turn away such work?  I don't know.

Tom Petch

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 6 Mar 2015 19:00:05 +0100

> would be no downgrade attack, "only" a MITM host diversion

Well, I to some case disagree and I also thought that that was what Sam pointed out...one wanted to communicate with something at foo.example.com, and if one "normally" did use HTTP over TLS and got a 301 or 302 back, and now instead do a similar change of target with the help of DNS, you do get something very similar at least to a downgrade attack.

But I understand what your point is -- I claim ;-)

   Patrik