Subject: [Ecrit] Consensus Call on U-NAPTR usage for LoST

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Mar 2008 22:26:47 +0200

Hi all,

I have just distributed a mail about a more detailed description on the 
usage of U-NAPTR for LoST discovery.

During the IETF#71 ECRIT session I asked the group for a hum whether the 
group wants to use
a) the input to the U-NAPTR process OR
b) the output of the U-NAPTR process
to be matched against the content of the identity information carried in 
the certificate exchanged as part of a TLS handshake between a LoST 
client and a LoST server.

There was strong consensus in the room for (b), as it is currently 
defined in the LoST document.

This mail aims to confirm that decision on the mailing list. Please post 
your opinion to the list.

Ciao
Hannes

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Mar 2008 07:36:47 -0400

Output, please

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Tuesday, March 18, 2008 4:27 PM
To: [email-masked]
Subject: [Ecrit] Consensus Call on U-NAPTR usage for LoST

Hi all,

Ciao
Hannes

---

From: Andrew Newton <[email-masked]>
Date: Wed, 19 Mar 2008 10:40:15 -0400

This does not take into account how the input data was acquired.  If  
it was acquired via DHCP, it could already be compromised.  This means  
that both options have security problems.  Therefore, the difference  
between these two options is that (a) will restrict the deployment  
options.  So I hum for (b).

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 19 Mar 2008 09:43:03 -0500

I hum for b) as well!

> Andrew Newton
> Sent: Thursday, 20 March 2008 1:40 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Ecrit] Consensus Call on U-NAPTR usage for LoST
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 19 Mar 2008 16:25:32 -0500

If I didn't hum for b, then I'd have to change my geopriv draft - it has
the same limitations.

b works for me, providing the limitations are adequately documented.
It's not as if it's your first and only option.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Winterbottom, James
> Sent: Thursday, 20 March 2008 1:43 AM
> To: Andrew Newton; Hannes Tschofenig
> Cc: [email-masked]
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> Of
> > Andrew Newton
> > > I have just distributed a mail about a more detailed description
on
> > > the
> > > During the IETF#71 ECRIT session I asked the group for a hum
> whether
> > > the
> > > group wants to use
> > > This mail aims to confirm that decision on the mailing list.
Please
> > > post
-----------------------------------------------------------------------
> -------------------------
-----------------------------------------------------------------------
> -------------------------
> [mf2]
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Mar 2008 23:28:36 +0200

> If I didn't hum for b, then I'd have to change my geopriv draft - it has
I guess you are talking about the LIS discovery document. Right?

> It's not as if it's your first and only option.
Ok. Thanks for the feedback.

Ciao
Hannes

>>> it was acquired via DHCP, it could already be compromised.  This
>>>       
>> means
>>     
>>>> the certificate exchanged as part of a TLS handshake between a
>>>>         
> LoST
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 21 Mar 2008 12:53:26 -0400

In favor of (b).  The security risks of U-NAPTR without DNSSEC are 
well-known; this case is not special.  This document should, however, 
state clearly that this risk exists, and how it can be mitigated in 
deployments.

--Richard