Hi Ilari, Thanks for the feed back. PLease see my comments inline. Yours, Daniel
On Wed, Sep 16, 2020 at 8:29 AM Ilari Liusvaara <[email protected]> wrote: > On Mon, Sep 14, 2020 at 11:11:03AM -0400, Daniel Migault wrote: > > Hi Nick, > > > > Thanks for the response and I apologize for my delayed response. However > I > > still have two major concerns regarding the current proposed text: > > > > Mentioning keyless as the only solution complementary to DC still seems > to > > me technically inaccurate. With KeylessSSL, the key server receives a > hash > > based on randoms and ECDH parameters. The hash used in TLS 1.3 is > different > > than in TLS 1.2 - when hashes are involved in the signature scheme - so > > Keyless would not work in this case - at least as far as I understand - > and > > significant changes are need to make it work in TLS 1.3. > > The way I understand Keyless is as generic mechanism. <mglt> Well the text mentions a remote signing mechanism - I understand as a generic mechanism - followed by a reference [KEYLESS]. That reference says: """ Our work focuses specifically on the TLS handshake proxying system implemented by CloudFlare in their Keyless SSL product """ So I am not convinced Keyless can be interpreted as a generic mechanism as opposed to a specific commercial solution. Note that I am not against KEYLESS being mentioned. I am just raising the issue this is not the only mechanism. My request is that, to appear generic multiple mechanisms could be mentioned [keyless, draft-mglt-lurk-tls12, draft-mglt-lurk-tls13]. At least I do not see how mentioning the other mechanisms would affect the genericity or the understanding. Note also these mechanisms were mentioned in previous versions of the draft. <mglt> The reason why the > Keyless paper did not discuss TLS 1.3 was that TLS 1.3 was very early > draft, and thus in significant flux, when the Keyless paper was published. > > Extending the signed-DH variant of Keyless to work with TLS 1.3 is > straightforward task. And there are already production implementations. <mglt> I am not saying that is hard to extend Keyless to TLS 1.3 nor to the TLS client side. I am just saying the reference does not seems to do what is described in the section. If there are already production implementations of Keyless with TLS 1.3 the ref might be updated I agree. I am happy to know which reference you would have in mind. Again I am not discussing whether Keyless should or should not be mentioned. I am willing to have other efforts being mentioned. </mglt> > It seems to me technically more accurate to mention the effort performed > on > > TLS 1.3 with draft-mglt-lurk-tls13 that is working in a TLS 1.3 context. > On > > the other hand, not mentioning it seems to me misleading. I also think it > > is misleading to not mention an effort that addresses the signing oracle > > security vulnerabilities associated to keylessSSL, leading to the > > impression that such attacks are inherent to the key server architecture > - > > with a dedicated section 7.6. I understand, though, > > that draft-mglt-lurk-tls13 is not a commercial product and still an > > ongoing effort. > > So far - unless I am missing them - I have not seen any technical > > justification for not mentioning that justify the single mention of > > keylessSSL and temptative of (non technical) procedural explanations do > not > > seem valid ( see in line ). > > IIRC, some analysis of Keyless type scheme found some security issues. > All but one was associated with RSA variant, and thus not a concern > with using TLS 1.3. The remaining one involved interaction with gQUIC. > AFAIK, the security issues with gQUIC that led to the problem have been > fixed (and iQUIC never had the problem to begin with). > > <mglt> The vulnerability I had in mind was the signing oracle where Keyless signs without context any provided hash value together with randoms. It is difficult for me to comment on the TLS 1.3 version of Keyless since I am not aware of it. The updated reference might help. That said, if the hash is being sent to the key server, the situation is not improved in terms of security over TLS 1.2. If the full handshake context is provided, then this would represent a significant change compared to the version used for TLS 1.2 - at least in term of performances. I also imagine that Ed25519 will take the full handshake. Even if the full handshake is provided, probably more thoughts are needed to see if that is sufficiently secure for both the TLS client or TLS server as well as how anti-replay protection is implemented. So to sum up further analysis is needed to be able to claim that keyless in TLS 1.3 does not have vulnerabilities and effectively represents an improvement over Keyless with TLS 1.2 Again I am not discussing whether Keyless should or should not be mentioned. I am willing to have other efforts to be mentioned. </mglt> And the way TLS 1.3 signatures are constructed, that harmful > interaction with gQUIC could trivially be prevented (preventing > that interaction with TLS 1.2 is a bit trickier, but still feasible). > > The section 7.6 stuff is only relevant to the RSA variant. There are > solid ways to prevent those issues. For example: > > 1) Use ECC keys. > 2) Use interface which only has message for signed-DH variant. > > Based on data I have seen, there is virtually no reason to support > RSA in TLS 1.2 or 1.3. I do not have seen corresponding data for TLS > 1.0 and 1.1. > <mglt> Just for clarification. does 2) means not to use in TLS 1.2 RSA authentication ? 1) seems to correspond to the modern cryptography [1]. I am unaware of the data you have in mind, but it seems to me that the use of RSA signature remains because of legacy or not-yet up-to-date clients. Overall I am not disagreeing with your statement but it seems until RSA is not deprecated vulnerabilities associated to RSA will remain. Maybe I am missing something. [1] https://wiki.mozilla.org/Security/Server_Side_TLS </mglt> > > Another concern I have - at least my understanding of it - is that DC is > > subject to downgrade attacks. Typically the TLS operator chooses the > > signature used by the DC to authenticate the server and this signature > > scheme can be weaker than the signature scheme provided by the CA. This > > prevents a content owner to enforce a (strong) level of authentication > and > > - in the future - the use of deprecated/weak signature schemes. The > threat > > model here is on the content owner perspective to ensure its website is > > strongly authenticated. The fact that the client can remove weak > signature > > schemes does not seem sufficient as nothing seems to force the client to > > only use strong authentication with SignatureSchemeList potentially > > appearing in clear. The threat model you seem to refer to is the client > to > > choose a strong authentication, but I think that is a bit different. > > The content owner can pick what algorithms he signs DCs for. Say that > the content owner has ECDSA P-384 certificate and wants comparable > authentication strength. Then he only signs DCs for ECDSA P-384 and > Ed448. This way there is no downgrade below 192-bit level. > > And in case of sudden cryptographic advance reducing strength of some > algorithm badly enough, that algorithm can be dropped quickly. > > <mglt> Looks this addresses my concern. The content owner controls the algorithm that is mentioned in the subject public key info. Thanks! </mglt> > > -Ilari > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > -- Daniel Migault Ericsson
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
