Re: [TLS] chairs - please shutdown wiretapping discussion...

[Stephen Farrell <[e-mail]>]

Hiya,

While we're waiting on Sean/Joe... :-)

On 10/07/17 14:54, Polk, Tim (Fed) wrote:
> First, I do not see this as a “wiretapping discussion” based on my
> reading of 2804, although others may disagree.

s/may/do/

Figure 3 in the draft is absolutely clearly describing
an architecture for wiretapping TLS connections. And I
see no way in which this scheme can avoid that problem
as there is no way in which the "TLS decrypter" can be
assured to be in any particular place in any network.
(If one did try fix that, then you end up in the mctls
muck.)

> 
> Second, I believe that this discussion should go forward based on
> several points:
> 
> 1.  this proposal does not involve any changes to the bits on the
> wire specified in the TLS 1.3 document 

I would assert that it substantially changes the semantics of
the bits emitted by standards-track TLS implementations. With
this, a client cannot know if it's application PDUs are being
decrypted from the middle of the network when talking to any
standards-compliant server. That basically breaks one of the
most important security properties of TLS.

> 2.  this proposal offers
> significantly better security properties than current practice
> (central distribution of static RSA keys) 

I fail to see any relevant difference in security properties
between those two, never mind a significant improvement.

> 3.  alternative solutions
> with significantly worse security properties are also feasible under
> TLS 1.3, and I would like to avoid them!

Yes. But that is not a justification to weaken security for
standards-track implementations of TLS1.3. We should not
standardise ways of doing crappy crypto would be my take.

> We should be in the business of developing pragmatic, interoperable
> solutions with appropriate security properties.  

Absolutely. This proposal, being inappropriate for the standards
track, should go visit /dev/null.

> Balancing
> cryptographic security with other security requirements to achieve
> such solutions should be an acceptable path, and pursuing this work
> in the TLS working group gives the IETF the best opportunity to
> influence these solutions.

See the raven mailing list I guess. That was specifically
discussed then.

S.


> 
> 
> 
> 
> 
> _______________________________________________ TLS mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/tls
>