Re: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate

[EKR <ekr@xxxxxxxxxxxxxxxxxxxx>]

Peter:

1. TLS has always included NULL cipher suites. They are in RFC 2246.
2. The IESG has already approved this document. It's in the 
   RFC Editor queue.
3. I think the current security considerations text is clear and 
   yours doesn't seem to to substantially improve matters.

-Ekr


Peter Williams <home_pw@xxxxxxx> writes:

> FINANCIAL DATA PROTECTION caveat , in INTEL null confidentiality scheme
> Im going to assume that Intel is only sponsoring this for "quality" PSK environments.. perhaps by supporting integration with TPM cores in Intel CPUs, which support external key fill, and thus support PSK by providing hardware-based external key management for TLS-PSK-based confidentiality services.
>  
> Perhaps, we can cut a deal. Change the text in the draft, security sections. 
>  
> There is a example disclaimer...which says something like "be advised: dont use this technique for sensitive information exchange. E.g. passwords". 
>  
> Change the example list to include specific financial account types: i) creditcard numbers, ii) bankaccount numbers, or iii) other Personal Identifying Financial Information
> As it stands, the goals of Intel as stated in the email (presumably addressing a few repressive regimes that want confidentiality - for any purpose - to be lowered to less than 40bit encryption (despite 40 bit encryption being shown even 10 years ago to be compromised in 3h, using a bit of brute-forcing commodity equipment!) ) is not compatible with the security section - which indicates that the technique is not appropriate for "sensitive information exchange". That incongruity aside, we can address my objection by listing - as inappropirate - those financial data -related account data types that I enumerate. 
>  
> Deal? 

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls