Hi Sean, Thanks for moving this along,
On 01/04/16 02:19, Sean Turner wrote: > On Mar 24, 2016, at 05:56, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: >> >> >> Hiya, >> >> Thanks for the speedy response... >> >> Again #3 below is what I care about, the other stuff isn't a big >> deal. >> >> On 24/03/16 00:38, Bodo Moeller wrote: >>> "Stephen Farrell" <stephen.farr...@cs.tcd.ie>: >>> >>>> (1) Why experimental? Wouldn't this be better as info and >>>> documented as "here's a spec for a thing that's widely >>>> deployed." I fear we may get questions like "what's the >>>> experiment?", "where's this going in future?" if this aims for >>>> experimental, and info may avoid that esp if we really want >>>> people to move to TLS1.3. I also didn't see list discussion >>>> about what kind of RFC to aim for, but maybe it was discussed >>>> at a meeting or interim? (Apologies if I missed that in my scan >>>> of the list.) >>> >>> I'm myself torn between "Experimental" and "Informational" >>> (certainly not "Historic" because the spec has not been >>> superseded by a more recent one and is not obsolete for any other >>> reason [ https://tools.ietf.org/html/rfc2026#section-4.2.4], >>> unless we somehow manage to complete TLS 1.3 standardization >>> before this). Taking into account how False Start is actually >>> deployed (and taking into >> >> Right. TLS1.3 will hopefully make this historic, so we could just >> park this in the RFC editor queue and have both RFCs emerge on the >> same day with this one as Historic. With did that with DKIM (4871) >> and DomainKeys (4870, Historic) for example. Note that I'm not >> arguing for doing that, just raising the option if that's what the >> WG want and if the list hasn't discussed it. I assume though that >> the WG don't want to take this route so no need to discuss it more >> in that case. >> >>> account that we expect it to eventually be replaced by a TLS 1.3 >>> mechanism) and how our I-D is cited in research papers on TLS, >>> "Experimental" sounds right to me: the spec really is part of a >>> research and development effort [ >>> https://tools.ietf.org/html/rfc2026#section-4.2.4]. >>> "Informational" wouldn't be wrong either. >> >> I think the latter matches much better myself, as there really is >> no experiment being done here and we're not gonna develop this any >> more once TLS1.3 is done, but whatever - I'm ok with saying that >> the WG just wanted experimental. But you'll likely get asked this >> again and again. At least we can now point at this thread and say >> that it was discussed on the list though. (Which was partly why I >> asked:-) >> >> It'd be no harm though if a couple of others chimed in on this just >> to there's recorded opinion from more than just the AD and an >> author. >> >> We can change to informational at the end of LC if need be, i.e., >> there's no need to hold stuff up for that and such a change then >> doesn't add any delay. > > > This draft started out as Informational and then we switched it > Experimental. The WG has not considered whether we should publish > this should go Historic now, be held and publish as Historic later, > etc. > > How do folks feel about Historic vs Experimental vs Informational? > > If we’re going to move it to Historic, then we’ve got a couple of > options: > > 0) As described above: Get it approved by the IESG, hold it in RFC > editor’s queue, and publish it as historic at the same time TLS 1.3 > is published. > > 1) Approve it, get it published, and then make it Historic with > another draft. > > 2) Approve it, get it published, and then make it Historic with an > IESG initiated Protocol Action, which is a message that the IESG > initiates requesting the status be changed similar to an IETF but > requires no draft. > > (there’s probably some other options like an adding an IESG note/new > section that says “this goes to historic when TLS 1.3 is published, > but I think the above three options seem more realistic.) > > Option 0 is probably the least amount of work. We just hold it, but > in some sense I kind of tend to think that we’re punishing the > authors. There’s nothing they’ve really got to do, but it feels > somehow like we’re hitting them upside the head with the process > two-by-four. > > Option 1 would be a total PITA. People say that we can get a draft > published quickly if we (the royal we) really want to, but my > experience is otherwise. > > Option 2 is something that I don't think we had in our toolkit when > DKIM was being worked on. The draft gets published the authors can > move on and we (the process moths) can make sure the draft gets moved > to Historic. > > What do the WG members think about the options of moving to historic? > Personally, I’d advocate option 2 because it keeps the work load on > the chairs/AD :) I'm fine with any of the above. > > ~snipped 2~ > >>> >>>> (3) Why is there no description of the reasons for all the MUST >>>> only use whitelisted <foo> and for the choices that are >>>> whitelisted? Wouldn't omitting that tend to lead people to use >>>> this more badly? >>> >>> Well, I tried to capture the general reasoning in the spec -- but >>> not the detailed reasons for the specific choices suggested, >>> because that again would just go stale quickly. >> >> Where are those general reasons stated? I don't see ‘em. > > The whitelisted options are described in the bullets in s4 and those > point to s5.* I'm still not seeing it. I do see things listed, but I don't see any reasons why the things are listed. The closest I see we get for now is: "The TLS protocol already relies on such a security property for authentication -- with False Start, the same is needed for encryption." But there's quite a gap between that statement and the set of rules given here. > > It’s stuff like don’t use suspect symmetric ciphers. But surely that's tautological? When would we ever recommend using dodgy stuff? I think what's missing is a description of or reference to what is particularly going to go wrong if you use a ciphersuite with known attacks and do false-start. That'd give the reader a chance to do an informed evaluation for themselves as to whether or not some ciphersuite is or is not safe with false-start. (And that evaluation will be done at various points in future.) > >>> In particular, I think this is an important observation in the >>> I-D: >>> >>> "If heuristically a small list of cipher suites and a single >>> protocol version is found to be sufficient for the majority of >>> TLS handshakes in practice, it could make sense to forego False >>> Start for any handshake that does not match this expected >>> pattern, even if there is no concrete reason to assume a >>> cryptographic weakness." >> >> That may be important but it doesn't address the issue about which >> I'm asking. >> >>> >>> So the whitelists should have algorithms that are actually used >>> in practice and that don't have critical weaknesses, but why >>> exactly those particular algorithms happen to get used in >>> practice is mostly out of scope here. >> >> Why is the logic behind such security relevant choices out of >> scope? That makes no sense to me. Let's imagine a new ciphersuite >> is invented and folks start to wonder whether or not it's ok to >> whitelist that for false-start - wouldn't they expect this document >> to explain (maybe mostly via references) why some ciphersuites are >> not good enough to whitelist? I would expect that to be clear. >> >> And to be clear, I'm not asking for an essay, but more like some >> text in the intro saying "False start is not safe for a ciphersuite >> that has properties <A,B,C> such as <example> because of <problem>. >> See [refs] for full details." >> >> For added clarity it'd also be good to have something like: >> "Ciphersuites MUST have <good-properties X,Y,Z> to be safe to >> whitelist for false-start." >> >> If figuring out text for the above is very hard, then I do think >> that would indicate a real issue with this spec. If figuring that >> out is just a minor bit of tedium, then I think it's worthwhile so >> that future readers of the RFC can understand what's going on here, >> which I don't think is the case from the current text. > > I think this text is already present: > > Clients MUST NOT use the False Start protocol modification in a > handshake unless the cipher suite uses a symmetric cipher that is > considered cryptographically strong. > > In the key exchange algorithms and client certificate type security > considerations, there’s: > > The recommended whitelists are such that if cryptographic algorithms > suitable for forward secrecy would possibly be negotiated, no False > Start will take place if the current handshake fails to provide > forward secrecy. > > .. and .. > > Forward secrecy can be achieved using ephemeral Diffie-Hellman or > ephemeral Elliptic-Curve Diffie-Hellman ... > > If we summarize these in the Introduction we’re good? No, I'm on about missing text not placement of text. Again if we added something like "False start is not safe for a ciphersuite that has properties <A,B,C> such as <example> because of <problem>. See [refs] for full details" then we'd be done because a reader could use that to analyse whether or not it is ok to use a future ciphersuite (or a current one, being re-evaluated in the future) with false-start. Cheers, S. PS: If I'm just not managing to explain myself well here, we can chat about it in B-A. > > spt > >> Cheers, S. >> >> >>> >>> Bodo >>> >>>> That could be done with some explanatory text and using some of >>>> the references below maybe. Or, if we don't really want new >>>> folks to implement this (do we?) then just saying that might >>>> mean it's ok to not explain the "why." (And then you could also >>>> address #1 above then by issuing this as an historic RFC too if >>>> you wanted.) >>> >> >> _______________________________________________ TLS mailing list >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
