Re: [Uta] Ben Campbell's Yes on draft-ietf-uta-xmpp-06: (with COMMENT)

[Peter Saint-Andre - &yet <[e-mail]>]

Hi Ben, thanks for the review.

On 4/21/15 3:53 PM, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-uta-xmpp-06: Yes
>
> 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 http://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:
> http://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 3.4, paragraph 3:
>
> Would you offer different guidance about the multi-tenant problem if POSH
> and DNA were finished? I don't suggest delaying for that, even though
> they are both post-WGLC. But I wonder if there is something here we need
> to clean up after POSH and DNA are published?

I think it's not a question of "published" but of "widely implemented 
and deployed". Thus, unfortunately, I would not foresee being able to 
absolutely mandate server-to-server authentication for at least a few 
years. However, that is certainly the goal. Do you think that additional 
text would be helpful here?

> Paragraph 4:
>
> By "unauthenticated connections", I assume it means "unauthenticated TLS
> [or encrypted] connections". Is this correct?


Good point: I think it would be best to make the following change.

OLD
    Given the pervasiveness of eavesdropping [RFC7258], even an
    unauthenticated connection might be better than an unencrypted
    connection in these scenarios (this is similar to the "better than
    nothing security" approach for IPsec [RFC5386]).  Unauthenticated
    connections include connections negotiated using anonymous Diffie-
    Hellman mechanisms or using self-signed certificates, among others.
    In particular for XMPP server-to-server interactions, it can be
    reasonable for XMPP server implementations to accept unauthenticated
    but encrypted connections when Server Dialback keys [XEP-0220] are
    used; such keys on their own provide only weak identity verification
    (made stronger through the use of DNSSEC [RFC4033]), but this at
    least enables encryption of server-to-server connections.  The DNA
    prooftypes described above are intended to mitigate the residual need
    for unauthenticated connections in these scenarios.

NEW
    Given the pervasiveness of eavesdropping [RFC7258], even an
    encrypted but unauthenticated connection might be better than an
    unencrypted connection in these scenarios (this is similar to the
    "better than nothing security" approach for IPsec [RFC5386]).
    Encrypted but unauthenticated connections include connections
    negotiated using anonymous Diffie-Hellman mechanisms or using
    self-signed certificates, among others.  In particular for XMPP
    server-to-server interactions, it can be reasonable for XMPP server
    implementations to accept encrypted but unauthenticated connections
    when Server Dialback keys [XEP-0220] are used; such keys on their
    own provide only weak identity verification (made stronger through
    the use of DNSSEC [RFC4033]), but this at least enables encryption
    of server-to-server connections.  The DNA prooftypes described above
    are intended to mitigate the residual need for encrypted but
    unauthenticated connections in these scenarios.

Rationale: the contrast is between (a) connections that are encrypted 
but not authenticated and (b) connections that are both encrypted and 
authenticated.

Peter

-- 
Peter Saint-Andre
https://andyet.com/