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
