Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS)

On Mon, May 11, 2015 at 4:30 PM, Alissa Cooper <alissa@cooperw.in> wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-tram-stun-origin-05: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This is a bit of a weird DISCUSS since I didn't manage to ballot when the
> document was first on the IESG's agenda, so I'm coming in mid-stream.
>
> I support Stephen's DISCUSS. If Alan's proposed changes make it into the
> document, they would resolve most of my concerns. However, I still see a
> problem with this proposed new text:
>
> "For STUN requests sent without authentication to a STUN server (i.e.
>
>    STUN binding requests sent to a STUN server), the STUN client SHOULD
>
>    include the ORIGIN attribute.  The ORIGIN attribute MUST NOT be
> included
>
>    if it is a "privacy-sensitive" context, as discussed in the Security
> Considerations
>
>    section."
>
> For requests sent with authentication, I understand that the origin
> attribute needs to be accurate in order for the client to authenticate.
> In those cases, the STUN server can rely on the attribute it receives.
> But for requests without authentication, what prevents the client from
> lying?

if the client is lying, then the request will not be authenticated and
it will be rejected - because the client's credentials will be
incorrect. I see that many people cannot grasp that very simple
concept. There is no benefits in lying in this case. Think about
ORIGIN as simply a logical virtual database name where the user
account will be searched and against that database the credentials
will be verified. This information is not sensitive, and lying is not
giving you any unjust benefits. The only outcome that you can achieve
by lying is screwing your own request - that's it.

> And if those requests are not (D)TLS-protected, what prevents them
> from being modified in transit? I understand Alan to be saying that the
> justification for the origin in this case is operational troubleshooting,
> but if the server can't rely on the origin it receives, doesn't that make
> it risky for the server to act on that information?

No, as I explained above.

>
> My additional concern is about the use of "logging" as a justification
> for including and origin attribute. Logging in and of itself is not a
> reasonable justification.

Why ?

> Alan's mail discussed the use of the origin for
> operational troubleshooting, which seems like what might actually be
> intended instead of "logging." In any event the purpose for the logging
> either needs to be explained or "logging" should not be listed as a
> justification.

Why ?

>
>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram