Re: [saag] draft-mm-wg-effect-encrypt-03

[Kathleen Moriarty <[e-mail]>]

Hi,

I'll start with responding to this message and then will respond to ones
with text for possible edits to the suggestions.

On Sun, Oct 16, 2016 at 2:27 PM, Stephen Farrell <[e-mail]>
wrote:

>
> Hi Al,
>
> On 16/10/16 18:19, MORTON, ALFRED C (AL) wrote:
> >
> > Clearly, changes in current management practices will be needed,
> > and that process could be more efficient with constructive input
> > from all involved. Understanding the many gaps is the first step,
> > and IMO, what this memo is about.  No arguing for solutions,
> > MITM or otherwise.
>
> I agree. Figuring out what solutions are needed for n/w
> management given the fact of much more ciphertext is work for
> another day and for other documents and WGs.
>
> I think what makes this tricky is that people understandably
> tend to mix up current solutions and requirements, e.g. it is
> natural enough (but wrong) to think that because I do X today
> that that implies doing X is required (and hence language like
> "valuable" etc.).
>

Yes, agreed.  As the draft stands now, before these additions that point is
very clear.  The intent is to document the purpose of activities, what is
used now so that other methods might be identified to achieve the same
goal, possibly via an entirely different mechanism.


> We directly saw that in the recent TLS WG discussion of RSA key
> transport, which was kicked off by (I think) the same set of
> folks. In the end the TLS WG chairs saw a very clear consensus
> to stick with PFS and to not add back RSA key transport to
> TLS1.3, despite RSA key transport being a "feature" on which
> it appears some enterprise networks still seem to depend for
> some forms of "attacking"/deciphering traffic to/from their own
> TLS servers.
>

I agree entirely with the consensus, not to worry.  I'll comb through the
proposed text to make sure the intended approach for the draft is
maintained.


>
> I think another related thing we need to be careful about here
> are claims of utility for features where there is little or no
> (at least public) evidence but only assertion. For example, many
> of the claims I hear about the effectiveness of scanning outbound
> traffic seem dubious to me, so we'll want to try find evidence
> to backup claims along those lines too if we want this document
> to be of most use later on. (Or to qualify such things as being
> e.g. "current practices for which there isn't such good evidence"
> or something.)
>

Yes, agreed.  For attack detection, we can confirm with MILE, but from my
experience attackers use whatever they would like to hide their tracks, so
worrying about TLS and the ability to break it doesn't really help anyway
as they'll just use something else.  I don't think that seeing into TLS
traffic is necessary for attack detection (Note: I have led incident
response and security teams that are quite advanced and consulted with
other teams that are quite advanced more recently. )  We can confirm with
MILE and DOTS as well, this should give us feedback from multiple industry
sectors.


>
> Buy hey, that's why you get all those big bucks for being such
> good document editors/authors I guess:-)
>

Ha.

Thanks,
Kathleen


>
> Cheers,
> S.
>
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>
>


-- 

Best regards,
Kathleen