Re: [TLS] draft-ietf-tls-prohibiting-rc4-01 opportunistic security

[Pete Resnick <[e-mail]>]

[Cc'ing the IESG, since this document is currently being discussed there]

FYI, just so this doesn't generate a long thread on TLS for no reason:

I am reading over the October WG list discussion on the draft where it 
appears this issue did come up, and my reaction so far is that I may 
simply be in the rough part of the rough consensus that existed on the 
list. That is, I think there is an issue here (i.e., the potential for a 
future OS implementation that, while being able to do better than RC4, 
may want to talk to something that can only either RC4 or clear text), 
but it looks like the WG did consider this objection and reasonably 
concluded that the current text is sufficient to cover the case. I do 
think it's a bit bogus for a document to say "implementations MUST NOT 
do X" when we know full-well that there is at least one good reason to 
ignore that requirement, but that's not enough for me to hold up the 
document. So unless I spot some point in the discussion of this topic 
that I think the WG really muffed, I'm almost certain to ballot No 
Objection before the IESG telechat tomorrow.

pr

On 1/7/15 11:20 PM, Dave Garrett wrote:
> https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ballot/403780/
>
> A reply to Pete Resnick's ballot comment for draft-ietf-tls-prohibiting-rc4-01:
>
> Under what opportunistic security implementation would something better than RC4
> not be supported by both endpoints? (I'm curious is one exists at all)
> Considering it permissible risks encouraging the usage of RC4 for opportunistic
> security, rather than more secure ciphers.
>
> If it is no longer fit for any purpose then the goal should be to kill it off
> entirely. Diluting the requirement risks compromising that goal. I'm not
> inclined to believe this is a "better than nothing" scenario unless there exists
> data on an existing RC4 OS system with a particularly large number of users that
> won't be upgraded. Though, in that case, they may just not honor this RFC.
>
> A simple requirement is best. I'm just sending this in the hope that this very
> good progress isn't made unnecessarily more complicated at the last second.
>
>
> Dave
>    

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]