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 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
