Hi Kathleen,
At 09:54 PM 12-11-2017, Kathleen Moriarty wrote:
The authors are concerned with user privacy and obstacles to deploying
encryption. If the obstacles are not documented and discussed,
adoption of encryption could suffer.
Thanks for that comment.
I'd be hesitant to add text that says it doesn't mean it's a good idea
as that would feed into the assumptions being made in this thread that
this draft is trying to prevent the deployment of encryption, when it
is just the opposite. Unless you mean that there should be a
statement that authenticated encryption is preferred?
Sorry for not being clear. The draft states that "NULL
Authentication with IPsec" has been implemented and deployed. Given
that it is a practice, is it a good idea? That was my point. The
document is length as it is. I don't think that adding more text
would make it better.
Stepping back, I'd say that the authors should decide what the
document is about. Is it about documenting what is in use by
operators? Is it a discussion of the practices? Is it about telling
the reader what the IETF recommends?
> In Section 2:
>
> "This and other increases in the use of encryption had the immediate
> effect of helping protect the privacy of users' data, but created a
> problem for some network management functions."
>
> Is this about privacy or is it about a security loophole?
That could depend on the content of data exposed. Are you suggesting
a text change?
There was a news article in the Washington Post about such an
issue. From what I recall, it was considered as a security issue. I
suggest looking at this from a security perspective.
If you break this sentence apart, the "import" part is the ability to
identify problems in application traffic. Many applications do a poor
job of logging, so DPI is sometimes used. A solution would be to
improve logging and debugging in applications, which is suggested in
the draft as an answer to many of the documented effects. I'm not
sure I follow your second question or what text led you to the
question? I read this sentence as saying it is one way it is done
today, because it is not working to do this directly with debug
information from the application. I read this as documenting what is
done and it leads me to think that applications need to improve their
debugging and logging capabilities.
The text which led me to the question is the second paragraph in
Section 2.1.2. The DPI specification (Y.2770) references RFC 3871;
it's related to logging capabilities (please see the paragraph quoted
above). DPI is about inspecting the traffic (including content)
passing through the network. The primary function of the DPI device
is not troubleshooting. Nowadays, the function is supposed to be DLP.
Why does an encrypted stream prevent the the network from being
excluded as "the problem"? If I understood the arguments in that
section, the IETF might as well recommend "cleartext" to make "the
internet work better".
> In Section 3.2.2:
>
> "STARTTLS ought have zero effect on anti-SPAM efforts for SMTP traffic."
>
> I doubt that STARTTLS cause any significant problem as the receiver has the
> ability to inspect emails.
So you agree with this statement? Or are you asking a question? If
you could clarify, I would appreciate it.
I don't understand why the document is discussing about
spam. Anyway, STARTTLS does not have any effect on spam
filtering. The sentence, as written, sounds like: in theory,
STARTTLS has zero effect ...
The last paragraph in Section 3.2.2 gets into "user-to-user
encryption" and provides a reference to a vendor. What does that
have to do with the heading for that section?
You may want to take another read of RFC7258. This is a early step in
one of the stated goals of that document - to find a balance between
protections and the ability to perform network management by
documenting the impacts to serve as a start to that conversation.
I read RFC 7258 and the draft once again.
Regards,
S. Moonesamy