I'm in favor of option 2.  Let's find a wording that is unambiguous.

Thanks
Sebastian


On Wed, Mar 06, 2013 at 09:25:50AM -0500, Wendy Roome wrote:
> Thanks, Michael. That's why I brought this up in the first place: I didn't
> know what that statement in -14 meant, and I wanted clarification. I can
> think of at least three interpretations:
> 
> 1. If an ALTO server chooses to do authentication/encryption, it must do
> it with SSL/TLS. That is, an ALTO server may choose to offer just an
> unsecured/unauthenticated http: interface, or just a secure https:
> interface, or both.
> 
> 2. A server must provide an encrypted/secure SSL/TLS interface as well as
> an unencrypted interface. That is, a compliant ALTO server must support
> both http: and https: requests.
> 
> 3. A server is only allowed to provide an encrypted/secure SSL/TLS
> interface. That is, a compliant ALTO server cannot accept unsecured http:
> requests.
> 
> I prefer #1. I can live with #2, but I don't think it's necessary. And I
> strongly oppose #3.
> 
>       - Wendy Roome
> 
> On 03/06/2013 08:32, "Scharf, Michael (Michael)"
> <[email protected]> wrote:
> 
> >> > Having said this, I could imagine that a "MUST" for TLS for
> >> the ALTO 
> >> > base protocol spec could avoid IESG pushback from the security area.
> >> > If so, I think a statement similar to IPFIX would be useful.
> >> 
> >> This isn't a topic to avoid IESG pushback, it is rather a
> >> topic of having a protocol that allows secured deployments
> >> across an untrusted network. And it should be up to the
> >> operator of the server to decide how much security is needed.
> >> 
> >> This is currently reflected in the draft (-14).
> >
> >For what it is worth, the exact phrasing in -14 confuses me: "An ALTO
> >Server MUST support SSL/TLS [RFC5246] to implement server and/or client
> >authentication, encryption, and/or integrity protection."  I could read
> >this in a way that the ALTO server MUST announce all services on HTTPS
> >URIs, and this is certainly not what we want. (And, having "and/or" in a
> >MUST statement might not be perfect.)
> >
> >If the consensus is the MUST, I'd at least prefer Sebastian's wording:
> >"Any ALTO implementation MUST support SSL/TLS [RFC5246]".
> >
> >Michael
> 
> 
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to