Re: [TLS] Additional TLS 1.3 results from Chrome
Hiya, On 19/12/17 01:59, Salz, Rich wrote: > However, since extension numbers are essentially infinite, this WG may > consider renumbering key_share to avoid the issue. > >> I think this would be fine, but not imperative. > > I think it would almost be hypocritical if we did not do it. > I'm not sure I agree renumbering is the right reaction, though I don't object to that. This could be a case where it's overall better that those specific devices suffer breakage, and hopefully then do get firmware updated to support TLS1.3 or TLS-without-extended-random-or-dual-ec at some point. WRT extended-random, it seems like the IETF process did work, in that we dropped the work. However, it may also be the case that the attacker's process (if one assumes that somewhere in the background (*) there was an attacker who wanted dual-ec attacks to be more efficient) also worked to at least some extent in that they got that to be deployed in some places, presumably at least partly based on the existence of the (then expired?) draft. I wonder if that argues for some kind of "dropped as a very bad idea" tombstone draft (or even RFC) for such cases? I can imagine that the IETF or TLS WG could do that, but I'm not sure if it'd have helped the developers of bsafe or those printers avoid the problem if such a thing had existed. In the case of extended-random, it is now clear that it is a very bad idea, even if that wasn't the case when the WG chose to not proceed with the work, so such a tombstone draft or RFC could be easily done and could possibly be useful. (I'm about half-convinced of that;-) One reason to think about this is that we have some more-current bad-idea drafts (e.g. draft-green) that we know are dead, but folks not involved in the WG might not be aware of that, so it could be good if those were somewhat more officially put to rest than just sitting forever as expired I-Ds. It'd be a fine thing if the authors of such drafts did that themselves of course, but if not, I'd volunteer to help:-) Cheers, S. (*) To be clear, I am not at all saying the authors of the extended-random draft were part of any attack. If I were the bad actor in such a case, I'd ensure the names that were public weren't in on the plan. signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Additional TLS 1.3 results from Chrome
“dropped as a bad idea” is an interesting end-state. Also “on hold for now” (which is how I want to see the TLS-breaking proposals). Having more I-D workflow options seems like something the IESG should take up. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Additional TLS 1.3 results from Chrome
Hiya, On 19/12/17 13:56, Salz, Rich wrote: > “dropped as a bad idea” is an interesting end-state. Also “on hold > for now” (which is how I want to see the TLS-breaking proposals). > > Having more I-D workflow options seems like something the IESG should > take up. > Well, TBH I doubt it'd be best done from the IESG down. If some WG wanted to pursue this kind of thing, I'd say it'd be much better done by the WG and then the IESG could get to decide what they think if/when such a draft is ever put forward by the WG for publication as an RFC. And for most WGs, there's little danger in expired I-Ds hanging about unchanged. For TLS, as we've seen in this case, there might be a downside to the expired I-D not containing text saying: "Don't do this! Really. And why." :-) As an aside, I'd say it'd be better to not think of this as a retraction, but more as a case of ensuring that the public record, as seen in the I-D repository, better reflects the WG consensus, for the few cases where there would be a concrete reason to not want people to write or deploy code implementing the draft concerned. For a WG draft, the WG itself can always decide that the right thing to happen is to publish a tombstone draft, so that could be handled easily enough. For a draft that's proposed for WG adoption, or that's discussed but not adopted, it might get complicated, if the authors don't agree that WG non-adoption is a good reason to put out a tombstone. (We'd likely need the WG to adopt the draft solely to put out the tombstone, which'd be a bit weird.) So as I said, I'm about half-convinced:-) Cheers, S. signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Additional TLS 1.3 results from Chrome
> I'm not sure I agree renumbering is the right reaction, though I don't > object to > that. This could be a case where it's overall better that those specific > devices > suffer breakage, and hopefully then do get firmware updated to support > TLS1.3 or TLS-without-extended-random-or-dual-ec > at some point. It's never better to break large numbers of things, if it can be avoided at low cost. The reaction isn't going to be "TLS 1.3 broke my printer, it's time to upgrade my firmware.", it's going to be "TLS 1.3 broke my printer, which was working perfectly fine. TLS 1.3 is bad. I wonder what else they got wrong. People shouldn't use TLS 1.3." -Tim smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Additional TLS 1.3 results from Chrome
On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farrell wrote: > I'm not sure I agree renumbering is the right reaction, > though I don't object to that. This could be a case where > it's overall better that those specific devices suffer > breakage, and hopefully then do get firmware updated to > support TLS1.3 or TLS-without-extended-random-or-dual-ec > at some point. > I think we would like to avoid deliberately breaking these devices with TLS 1.3. (I think TLS 1.3 has been subject to enough friction already.) If key_share is renumbered, then presumably extension 40 would be reserved by IANA. Thus other implementations could send extension 40 if they wish not to interoperate with extended_random-supporting peers. Cheers AGL ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
