On Tue, Oct 6, 2015 at 11:42 PM, Watson Ladd <watsonbl...@gmail.com> wrote:
> I have two major comments. The draft recapitulates bits and pieces of > the TLS 1.3 draft, but it's not clear why this is done instead of > citing that draft. I was explicitly asked to by the WG. Personally, I agree with you that it would be better to cite the TLS 1.3 draft. > I also don't understand what it means to support a > bare public key: what exactly is to be done with this key, how is it > distinguished from the case of X509 certificate, is there are RFC > already defining this feature in TLS 1.2, etc. Yes. It's in RFC 7250. I'm just citing that. > Similar questions apply > to TOFU. > I don't think the > There is also an interesting consideration: suppose a server > implements this draft by signaling to applications they should > negotiate TLS, and a client is on a system which just does it. The > client is unmodified, but itself wishes to use TLS by sending a > ClientHello etc. Now the two try to connect, and the server receives a > ClientHello it wasn't expecting. > I'm not sure I follow the use case, but if I understand correctly, generally it's not safe to send ClientHello to people who aren't expecting it. -Ekr Sincerely, > Watson Ladd > > On Tue, Oct 6, 2015 at 5:24 PM, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: > > > > Hiya, > > > > The TCPINC WG have been having a hard time in picking an approach > > to take with two reasonable proposals on the table. [1,2] > > > > The tcpcrypt draft [2] has been around for a while and has had a > > good bit of review so its content is fairly well understood. > > > > The idea of the TLS approach has also been around for a while, but > > the nitty-gritty details are really only documented in [1] in > > the current revision. > > > > The chair of TCPINC intends to try again to poll the WG about > > adopting drafts in the relatively near future and has asked if we > > can get some security folks to review [1] in the next week or so. > > > > What's being asked for here is a review of the content of [1] and > > *not an analysis of [1] vs. [2]*. The WG have probably seen all of > > the arguments there already, so the ask now is really just to get > > some more eyeballs on the content of [1] before the WG consider > > adopting a draft (again;-). > > > > So, if one or two of you could please do a review of [1] in the > > next week or so and post that to the TCPINC mailing list (which > > believe it or not is tcpinc@ietf.org:-), that'd be great. If you > > know TLS (esp the ongoing work on TLS1.3) and TCP it ought not be > > much work to do that. > > > > Aside from that, fresh voices or arguments in the [1] vs. [2] debate > > are of course also always welcome on the WG list, but please do > > check the WG archive to see if an argument is really fresh - most of > > the pros and cons have already been aired I think. > > > > Thanks in advance, > > S. > > > > [1] https://tools.ietf.org/html/draft-rescorla-tcpinc-tls-option-04 > > [2] https://tools.ietf.org/html/draft-bittau-tcpinc-tcpcrypt-03 > > > > _______________________________________________ > > saag mailing list > > s...@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc >
_______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
