On 9/22/14, 4:31 PM, Viktor Dukhovni wrote:
On Sun, Sep 21, 2014 at 11:15:20PM +0300, Yaron Sheffer wrote:
o Host name validation is sometimes irrelevant.
While it is true that insecurely obtained hostnames are not suitable
"reference identifiers" for peer authentication, it is perhaps not
enough to suggest that the hostname should not be used, the text
perhaps ought to say that something else should be used instead.
However, there is another case in which name checks don't apply at
all, and that is peer authentication via DANE-EE(3) TLSA records,
in which the name to public key binding is via DNSSEC, not the
certificate payload.
o Session identities are not protected, only tickets are.
I'm not sure what it means for "resumption information" to be
authenticated, and who is supposed to perform this authentication.
I think what is perhaps meant is that clients (that are in the
target audience of the document) should not cache sessions for
which peer authentication (including any application peername
verification) failed at session establishment.
o Clarified the target audience.
The acronyms SMTPS, IMAPS, POPS, XMPPS, IRCS are not introduced
anywhere. While a few of these may in lower-case occur in
/etc/services files on some systems, I am not aware of any standard
protocol called SMTPS (I'll let others speak to the existence of
IMAPS, ...).
Also it is I think inappropriate to suggest that MTA to MTA SMTP
with STARTTLS is in scope for the intended "strict" TLS profile of
the draft. For quite some time TLS with MTA to MTA SMTP will employ
opportunistic security, with authentication optional.
Yes, this text might be a bit misleading:
Concerning deployment, this document targets a wide
audience, namely all deployers who wish to add authentication,
confidentiality and data integrity to their communications. This
document does not address the rare deployment scenarios where one of
these three properties is not desired.
Unauthenticated encryption is also quite common for server-to-server
communication on the XMPP network.
Peter
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
