Subject: Re: [IPsec] #117: Hash and URL interop

From: Yaron Sheffer <[email-masked]>
Date: Tue, 24 Nov 2009 19:09:24 +0200

Resending. There may be value in other URL methods, just maybe, but OTOH they would confuse developers and add security issues.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Friday, October 30, 2009 1:18
To: IPsecme WG
Subject: [IPsec] #117: Hash and URL interop

To improve interoperability, allow only the "http" URL method. The current text (end of sec. 3.6) implies that any method is allowed, although HTTP MUST be supported.

Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Nov 2009 10:24:43 -0800

>Resending. There may be value in other URL methods, just maybe, but OTOH they would confuse developers and add security issues.

I agree with only listing HTTP.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Nov 2009 10:32:15 +0200

+1

Even things that seem obvious like https and ftp require a lot of considerations, like how to verify the certificate in https, or what identity to present in ftp.

If someone wants to specify additional URL methods, they can specify then in an I-D.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Nov 2009 13:54:59 +0200

Yaron Sheffer writes:
> Resending. There may be value in other URL methods, just maybe, but
> OTOH they would confuse developers and add security issues.

I still reiterate that I do not think we can add "MUST NOT" for other
URL methods, as that would be change that can make existing
implementations non-conforming (if they happen to send some other url
methods).

We have been in other cases careful not to make changes that could
make currently conforming implementations non-conforming, so I think
this should be similar case.

Btw, our implementation only sends http urls for now.

> To improve interoperability, allow only the "http" URL method. The
> current text (end of sec. 3.6) implies that any method is allowed,
> although HTTP MUST be supported. 

I still think the current text mandating one method (MUST for http)
provides good enough interoperability. I do not see nede to change
this.

See my previous comment about this:
http://www.ietf.org/mail-archive/web/ipsec/current/msg04987.html
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Nov 2009 15:52:18 +0200

Yoav Nir writes:
> Even things that seem obvious like https and ftp require a lot of
> considerations, like how to verify the certificate in https, or what
> identity to present in ftp. 
> 

Yes, and but if the current documents says MUST NOT for them, then
they can have problems talking to the current implementations.

On the other hand nobody has yet answered to my earlier question what
they plan to say in the draft. Original text said "allow only http
URL", and I said MUST NOT would not be ok for me.

> > I agree with only listing HTTP.

which does not tell what he means with that. Do he mean that we only
list http (currently we do that, we say MUST for http urls and do not
list any other url methods). 

So I would really like to see the exact wording before I can say
anything else. Or at least better explination what is meant. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 25 Nov 2009 16:44:18 +0200

Can you live with:

Implementations MUST support HTTP. The behavior of other URL methods is not currently specified, so such methods SHOULD NOT be used in the absence of a Standards Track document defining them.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tero Kivinen
> Sent: Wednesday, November 25, 2009 15:52
> To: Yoav Nir
> Cc: IPsecme WG; Paul Hoffman
> Subject: Re: [IPsec] #117: Hash and URL interop
> 
> Yoav Nir writes:
> Yes, and but if the current documents says MUST NOT for them, then they
> can have problems talking to the current implementations.
> 
> On the other hand nobody has yet answered to my earlier question what they
> plan to say in the draft. Original text said "allow only http URL", and I
> said MUST NOT would not be ok for me.
> 
> Paul said:
> 
> which does not tell what he means with that. Do he mean that we only list
> http (currently we do that, we say MUST for http urls and do not list any
> other url methods).
> 
> So I would really like to see the exact wording before I can say anything
> else. Or at least better explination what is meant.
> --
> [email-masked]
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Nov 2009 17:25:14 +0200

Yaron Sheffer writes:
> Can you live with:
> 
> Implementations MUST support HTTP.

This is already in the RFC4306.

> The behavior of other URL methods is not currently specified, so
> such methods SHOULD NOT be used in the absence of a Standards Track
> document defining them.

This addition is ok for me, altough I do not think we need to have
*Standard Track* documents to be able to use, I would just say "in the
absens of document defining them". I think having information RFC
telling how to use ftp URLs should be ok, especially as some people
might be against making such document standard track document.
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 25 Nov 2009 10:33:40 -0500

> might be against making such document standard track document.

I agree.

As an aside, I would expect any such document not only to loosely specify 
the behavior of https or ftp URLs (for example), but also to introduce new 
notify types such as HTTPS_CERT_LOOKUP_SUPPORTED and 
FTP_CERT_LOOKUP_SUPPORTED.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
Tero Kivinen <[email-masked]>
To:
Yaron Sheffer <[email-masked]>
Cc:
IPsecme WG <[email-masked]>, Yoav Nir <[email-masked]>, Paul Hoffman 
<[email-masked]>
Date:
11/25/2009 10:25 AM
Subject:
Re: [IPsec] #117: Hash and URL interop

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Nov 2009 08:20:59 -0800

>Implementations MUST support HTTP. The behavior of other URL methods is not currently specified, so such methods SHOULD NOT be used in the absence of a Standards Track document defining them.

No. There is no technical or interop reason for the SHOULD NOT. Everyone MUST support HTTP and the rest is up to them. If someone later specifies how to do FTP or whatever, that is fine.

--Paul Hoffman, Director
--VPN Consortium