Re: [TLS] Some comments on draft-rescorla-tls-esni-00
John, Thanks for your comments. It's good to know that someone has already done this! On Fri, Jul 20, 2018 at 12:52 PM, John Mattsson wrote: > Hi, > > I looked through the draft, mainly focusing on the crypto parts. This is > more or less ECIES, but with a more modern style of key derivation that > most existing standards. This solution is very similar to the standardized > 3GPP identity encryption (SUCI) with the difference that the static public > keys are distributed through DNS instead of UICCs (aka SIM cards). > > The current construction looks very good. > > - One thing that could be discussed is integrity protection of the > client’s ephemeral public key. The current construction > > encrypted_sni = AEAD-Encrypt(key, iv, "", PaddedServerNameList) > > does not achieve IND-CCA security (but only suffers from benign > malleability [1][2]). An addition of the client’s key share would make the > SNI encryption IND-CCA secure: > > encrypted_sni = AEAD-Encrypt(key, iv, KeyShareClientHello, > PaddedServerNameList) > > Unless it causes problems of some kind, I would recommend doing that. > Thanks. This seems like a good plan. Would an acceptable alternative be to hash the KeyShare into the key? > - The hash algorithm used in “Hash(ClientHello.Random)” does not seem to > be stated. I assume that it is the hash function associated with "suite". Yes. > Also, is hashing the random value needed? > No, it's just a result of the slightly goofy HKDF-Expand-Label interface. -Ekr - A mistake ECIES implementations has done in the past is to let the > integrity key depend on the plaintext which breaks the security proof of > ECIES, but this is not the case here. > > Cheers, > John > > [1] http://www.secg.org/sec1-v2.pdf > [2] http://shoup.net/papers/iso-2_1.pdf > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Some comments on draft-rescorla-tls-esni-00
Hi, I looked through the draft, mainly focusing on the crypto parts. This is more or less ECIES, but with a more modern style of key derivation that most existing standards. This solution is very similar to the standardized 3GPP identity encryption (SUCI) with the difference that the static public keys are distributed through DNS instead of UICCs (aka SIM cards). The current construction looks very good. - One thing that could be discussed is integrity protection of the client’s ephemeral public key. The current construction encrypted_sni = AEAD-Encrypt(key, iv, "", PaddedServerNameList) does not achieve IND-CCA security (but only suffers from benign malleability [1][2]). An addition of the client’s key share would make the SNI encryption IND-CCA secure: encrypted_sni = AEAD-Encrypt(key, iv, KeyShareClientHello, PaddedServerNameList) Unless it causes problems of some kind, I would recommend doing that. - The hash algorithm used in “Hash(ClientHello.Random)” does not seem to be stated. I assume that it is the hash function associated with "suite". Also, is hashing the random value needed? - A mistake ECIES implementations has done in the past is to let the integrity key depend on the plaintext which breaks the security proof of ECIES, but this is not the case here. Cheers, John [1] http://www.secg.org/sec1-v2.pdf [2] http://shoup.net/papers/iso-2_1.pdf ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Proposed changes to draft-ietf-tls-subcerts
> Because it means that if the client does not understand DC, then it must > reject the certificate, ... This is the desired behavior, as far as I understand. > ... but if client understands DC, it can accept it even in non-DC contexts. I don't see why this is nonsensical. One way to understand this is that the server is presenting a certificate that it only wants to use with DC-capable clients. Perhaps noone would want to actually use this configuration, but I don't see why it should be deemed invalid. > The other mismatch case also has well-defined technical meaning, it > means that client that does not understand DC can use the certificate, > but client that understands DC can only use it in DC context. I don't quite understand. The issue I believe you pointed out is that when the extension is non-critical, but the strict flag is set, the server will be compelled to serve a DC even if the client doesn't support it. The relevant text (you'll have to look at the source on GitHub) is: "The extension MAY be marked crititcal. (See Section 4.2 of [RFC5280].) If the strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an “illegal_parameter” alert." A client who doesn't speak DC will either abort with an "unexpected_message" alert, or if it ignores the extension, then verification of the handshake will fail, since it's using the end-entity certificate public key, and not the DC public key. Thus, I believe the only valid configurations are: * strict=true, crit=true; * strict=false, crit=true; and * strict=false, crit=false. The revised text should be: "If the strict boolean is set to true, then the extension MUST be marked critical; otherwise it MAY be marked non-crititcal. If the strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an “illegal_parameter” alert. -Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Doubts about a solution or new service/protocol
On Friday, 20 July 2018 17:41:23 CEST Walter Neto wrote: > Hi guys, after I saw I did not express myself clearly I decided to write > this message trying to do that. > > The actors: > A - The business company that needs to emitt the invoice; > B - The Brazilian Internal Revenue Service, who requires "A" to emit > invoices using "B" webservices; > C - The software company that emits the invoice for company "A" through "B" > webservices. > > The current Brazilian common model: > > "A" pass to "C" his certificate who uses it to sign and communicate it > through "C" webservices. > > For me here we have a serious security problem, once this private keys is > shared between "B" employees. yes it is > My proposal: > > To exist a service that TLS Client implementations consume to make the tasks > who only the certificate private key detainer can do. TLS client certificates sign just the handshake, they don't sign the contents of the exchanged messages, both the client and the server have keys that can be used to create messages looking as if they were created by either side of connection, so you can't say if the messages were created by an "evil" server, or are genuine worse still, as the exchanged data is authenticated either with HMAC or some form of AEAD tag (so symmetric crypto), when you are able to verify the messages as genuine, you also are able to forge them so no, TLS itself is not the technology that can be used to solve this > Regards, > > On Mon, Jul 16, 2018 at 3:30 PM Walter Neto wrote: > > Sorry Ted, I think I was not so clear. > > > > We use https (http over tls) to transmit this invoice files and I think it > > will be great if we have the option on the tls protocol to ask another > > service to encrypt things to it, without having the certificate (with > > private key).> > > On Mon, Jul 16, 2018 at 1:50 PM Ted Lemon wrote: > > > Why do you need to extend tls to do this? Why not just use it for > > > encapsulation? What you are describing sounds more like pgp than tls.> > > > > On Mon, Jul 16, 2018 at 12:15 PM Walter Neto wrote: > > >> Hi IETF tls list, > > >> > > >> I have some problem to solve I believe it is good to make my questions > > >> and > > >> proposals here. > > >> > > >> I'm from Brazil, here we need to use X.509 certificates to sign > > >> electronic > > >> invoices XMLs and to communicate this XMLs through https. > > >> > > >> The problem is that the most of emitters pass their certificates (with > > >> private and public keys) to the software companies that communicate > > >> this invoices, what in my point of view it is so insecure, the other > > >> problem is that generate a certificate to the software company > > >> authorized to emmit the invoice is so bureaucratic. > > >> > > >> My proposal is to create a service that generates tokens to third > > >> applications use this service to sign, and encrypt data without the > > >> certificate, and introduce an option in the tls protocol to pass the > > >> token and the service address to use it when don't have local cert > > >> files. > > >> > > >> Does it make sense? > > >> > > >> -- > > >> Walter Neto > > >> > > >> ___ > > >> TLS mailing list > > >> TLS@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tls -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Doubts about a solution or new service/protocol
IMHO no it doesn't. TLS is just a way to provide secure pipes between the communicating entities. Making long-term signatures that persist after the connection is dropped had never been on the site of TLS. Regards, Uri Sent from my iPhone > On Jul 20, 2018, at 11:42, Walter Neto wrote: > > Hi guys, after I saw I did not express myself clearly I decided to write this > message trying to do that. > > The actors: > A - The business company that needs to emitt the invoice; > B - The Brazilian Internal Revenue Service, who requires "A" to emit invoices > using "B" webservices; > C - The software company that emits the invoice for company "A" through "B" > webservices. > > The current Brazilian common model: > > "A" pass to "C" his certificate who uses it to sign and communicate it through > "C" webservices. > > For me here we have a serious security problem, once this private keys is > shared > between "B" employees. > > My proposal: > > To exist a service that TLS Client implementations consume to make the tasks > who > only the certificate private key detainer can do. > > Does this proposal make sense? > > Regards, >> On Mon, Jul 16, 2018 at 3:30 PM Walter Neto >> wrote: >> >> Sorry Ted, I think I was not so clear. >> >> We use https (http over tls) to transmit this invoice files and I think it >> will >> be great if we have the option on the tls protocol to ask another service to >> encrypt things to it, without having the certificate (with private key). >> >>> On Mon, Jul 16, 2018 at 1:50 PM Ted Lemon wrote: >>> >>> Why do you need to extend tls to do this? Why not just use it for >>> encapsulation? What you are describing sounds more like pgp than tls. >>> On Mon, Jul 16, 2018 at 12:15 PM Walter Neto wrote: Hi IETF tls list, I have some problem to solve I believe it is good to make my questions and proposals here. I'm from Brazil, here we need to use X.509 certificates to sign electronic invoices XMLs and to communicate this XMLs through https. The problem is that the most of emitters pass their certificates (with private and public keys) to the software companies that communicate this invoices, what in my point of view it is so insecure, the other problem is that generate a certificate to the software company authorized to emmit the invoice is so bureaucratic. My proposal is to create a service that generates tokens to third applications use this service to sign, and encrypt data without the certificate, and introduce an option in the tls protocol to pass the token and the service address to use it when don't have local cert files. Does it make sense? -- Walter Neto ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > > > -- > -- > Walter Neto > > ___ > 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
Re: [TLS] Proposed changes to draft-ietf-tls-subcerts
On Thu, Jul 19, 2018 at 08:39:11PM +, Patton,Christopher J wrote: > > Now let's check the converse. Suppose that the crit=true. Is it valid > for strict to be false? Yes, because the extension being critical > only means that the client has to understand DC in order to accept > the certificate. But this doesn't mean they must negotiate a DC. It might have well-defined technical meanining, but I consider it nonsensical. Because it means that if client does not understand DC, it must reject the certificate, but if client understands DC, it can accept it even in non-DC contexts. The other mismatch case also has well-defined technical meaning, it means that client that does not understand DC can use the certificate, but client that understands DC can only use it in DC context. I do not consider either of these two cases sensible. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Doubts about a solution or new service/protocol
Hi guys, after I saw I did not express myself clearly I decided to write this message trying to do that. The actors: A - The business company that needs to emitt the invoice; B - The Brazilian Internal Revenue Service, who requires "A" to emit invoices using "B" webservices; C - The software company that emits the invoice for company "A" through "B" webservices. The current Brazilian common model: "A" pass to "C" his certificate who uses it to sign and communicate it through "C" webservices. For me here we have a serious security problem, once this private keys is shared between "B" employees. My proposal: To exist a service that TLS Client implementations consume to make the tasks who only the certificate private key detainer can do. Does this proposal make sense? Regards, On Mon, Jul 16, 2018 at 3:30 PM Walter Neto wrote: > > Sorry Ted, I think I was not so clear. > > We use https (http over tls) to transmit this invoice files and I think it > will > be great if we have the option on the tls protocol to ask another service to > encrypt things to it, without having the certificate (with private key). > > On Mon, Jul 16, 2018 at 1:50 PM Ted Lemon wrote: > > > > Why do you need to extend tls to do this? Why not just use it for > > encapsulation? What you are describing sounds more like pgp than tls. > > > > On Mon, Jul 16, 2018 at 12:15 PM Walter Neto > > wrote: > >> > >> Hi IETF tls list, > >> > >> I have some problem to solve I believe it is good to make my questions and > >> proposals here. > >> > >> I'm from Brazil, here we need to use X.509 certificates to sign electronic > >> invoices XMLs and to communicate this XMLs through https. > >> > >> The problem is that the most of emitters pass their certificates (with > >> private > >> and public keys) to the software companies that communicate this invoices, > >> what > >> in my point of view it is so insecure, the other problem is that generate a > >> certificate to the software company authorized to emmit the invoice is so > >> bureaucratic. > >> > >> My proposal is to create a service that generates tokens to third > >> applications > >> use this service to sign, and encrypt data without the certificate, and > >> introduce an option in the tls protocol to pass the token and the service > >> address to use it when don't have local cert files. > >> > >> Does it make sense? > >> > >> -- > >> Walter Neto > >> > >> ___ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls -- -- Walter Neto ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt
On 07/09/2018 05:40 PM, Kathleen Moriarty wrote: > Stephen and I posted the draft below to see if the TLS working group > is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has > been a recent drop off in usage for web applications due to the PCI > Council recommendation to move off TLSv1.0, with a recommendation to > go to TLSv1.2 by June 30th. NIST has also been recommending TLSv1.2 > as a baseline. Applications other than those using HTTP may not have > had the same reduction in usage. If you are responsible for services > where you have a reasonable vantage point to gather and share > statistics to assess usage further, that could be helpful for the > discussion. I have access to stats from a small UK-based ESP. Of the inbound: SMTP connections in plaintext: 15% Of TLS: SMTP using TLS version prior to 1.2 : 20% SMTP using TLSv1.1 : 0.03% I note specifically that Facebook notification mails use TLSv1.0 -- Cheers, Jeremy ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Fri, Jul 20, 2018 at 08:42:47AM -0400, David Benjamin wrote: > > (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 is > probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don't > think we actually believe SHA256 and SHA384 give related output. It's just > nice to avoid the assumption. Whereas TLS1.2-PRF-SHA256 and HKDF-SHA256 > actually a chance of misbehavior. Perhaps it's worth doing that analysis?) TLS 1.3 does this with PSK: HMAC(, PSK) And TLS 1.2 does: HMAC(, ) (where actually depends on ). Now, it is possible that there is second similar block in there, but that uses the same . However, noteworthy point is that there is only two ways to end up in situation where the effective key in TLS 1.2 is all zeroes: 1) is longer than hash block and is preimage of 0. Finding such thing is supposed to be infeasible. 2) The PSK is empty. However, the on TLS 1.2 side is not empty in this case (it starts with gunk from HMAC that involves at least both randoms). Also, empty PSK is not secure. The definition of HMAC is: H(C(key) XOR opad | H(C(key) XOR ipad, data)) Which preserves collision resistance on C(key) and data. Now, C(key) is not collision resistant. However, the only possible cases where C(key) can collide are the two above. So it seems to me that TLS 1.2 and TLS 1.3 compute independent things from PSK values, in all practical cases. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Fri, Jul 20, 2018 at 7:39 AM Nikos Mavrogiannopoulos wrote: > On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote: > > > > > > > This is somewhat timely, as if we do want to introduce a > > > restriction, > > > > it > > > > would ideally be in the form of some text in the TLS 1.3 > > > > specification, > > > > which is very nearly done. > > > > > > > > It would be good to hear more opinions on this question, > > > particularly > > > > from those who have worked on the formal verification directly. > > > > > > > > If I can attempt to summarize some discussion that occurred in > > > the > > > > mic > > > > line today, Hannes was surprised that we would care, likening > > > this > > > > case > > > > to the regular version negotiation, where we are happy to use the > > > > same > > > > certificate to sign messages for both TLS 1.2 and 1.3. David > > > > Benjamin > > > > points out that we explicitly go to the trouble of putting 64 > > > bytes > > > > of > > > > 0x20 padding at the front of the content that gets signed for > > > > CertificateVerify, to enforce separation between the TLS > > > versions. > > > > > > > > My own personal opinion is that we should enforce a domain > > > separation > > > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's > > > "Universal > > > > PSKs" > > > > proposal seems like a potential mechanism by which to do so > > > without > > > > doubling the provisioning needs. > > > > > > I think the same rules should apply for PSK and RSA/ECDSA/EdDSA > > > keys. > > > There is no inherent difference between the two keys types. I could > > > have deployed TLS with PKI or TLS with PSK. I should be able to > > > upgrade > > > protocols the same way. > > > > > > If RSA keys can be re-used between TLS1.2 and TLS1.3, then so > > > should > > > PSK keys. The current document specifically allows that re-use, and > > > if > > > you fear that the current document did not take cross-protocol > > > attacks > > > in mind during design, then let's fix that instead. > > > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > > different KDFs, which we don't have any analysis for > > I understand, but as I have already mentioned that argument also > applies for RSA keys which can be used e.g., for RSA encryption under > TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be used > with multiple hashes under TLS1.2 while only one under TLS1.3. > TLS 1.3 did not enforce protocol separation for that ugly scenario, so > I wouldn't expect the treatment of PSKs differently. > PSKs are much easier to fix this with than signing algorithms, given that we don't want to reprovision either to deploy TLS 1.3. ECDSA in TLS didn't get worse with TLS 1.3. We didn't add a new hash to mixup, just restricted the set from TLS 1.2. If we left it alone, we'd still have the same effect. For RSA, you're right that we introduced an extra pair of algorithms to worry about. The options there are: (1) Add PSS, forbid PKCS1, and forbid PSS with id-rsaEncryption. Cost: TLS 1.3 requires reprovisioning RSA keys. (2) Add PSS, forbid PKCS1, but allow PSS with id-rsaEncryption. Cost: We have two algorithms with one key. (3) Don't forbid PKCS1. Cost: We don't get rid of PKCS#1. (1)'s cost is clearly fatal, given 1.3's goals. I'm personally fine with either (2) or (3), but the WG chose (2). With PSKs, I think we can get both. If we consider 1.2 PSKs to be paired with the 1.2 PRF, we can allocate a new label, and derive a separate thing to stick in 1.3, and not require reprovisioning. It's basically free, so I think it makes sense to do it. (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 is probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don't think we actually believe SHA256 and SHA384 give related output. It's just nice to avoid the assumption. Whereas TLS1.2-PRF-SHA256 and HKDF-SHA256 actually a chance of misbehavior. Perhaps it's worth doing that analysis?) Of course, I don't actually know what I'm talking about. Opinions from the formal analysis folks would be great. :-) > Said that, I want to clarify that I wouldn't necessarily object to an > improvement the situation for externally established PSKs. The issue I > see is that TLS1.3 already gives a "good enough" solution with re-using > the key, and I'm afraid we're going to have interoperation issues if > some implementations move to universal psks and some do not, defeating > the purpose of a standard. > I think that's the point of deciding this immediate question now, so we can get some text in the specification. If we decide to fix this, we'd instruct implementations to (temporary!) turn off TLS 1.3 if 1.2 PSKs are configured and then, once the fixup document is published, implement it and remove the version logic. This is interoperable at all combinations as version negotiation runs first. Personally, I actually don't care much about 1.2 PSKs as I don't work with anything that uses them
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Fri, Jul 20, 2018 at 4:39 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote: > > > > > > > This is somewhat timely, as if we do want to introduce a > > > restriction, > > > > it > > > > would ideally be in the form of some text in the TLS 1.3 > > > > specification, > > > > which is very nearly done. > > > > > > > > It would be good to hear more opinions on this question, > > > particularly > > > > from those who have worked on the formal verification directly. > > > > > > > > If I can attempt to summarize some discussion that occurred in > > > the > > > > mic > > > > line today, Hannes was surprised that we would care, likening > > > this > > > > case > > > > to the regular version negotiation, where we are happy to use the > > > > same > > > > certificate to sign messages for both TLS 1.2 and 1.3. David > > > > Benjamin > > > > points out that we explicitly go to the trouble of putting 64 > > > bytes > > > > of > > > > 0x20 padding at the front of the content that gets signed for > > > > CertificateVerify, to enforce separation between the TLS > > > versions. > > > > > > > > My own personal opinion is that we should enforce a domain > > > separation > > > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's > > > "Universal > > > > PSKs" > > > > proposal seems like a potential mechanism by which to do so > > > without > > > > doubling the provisioning needs. > > > > > > I think the same rules should apply for PSK and RSA/ECDSA/EdDSA > > > keys. > > > There is no inherent difference between the two keys types. I could > > > have deployed TLS with PKI or TLS with PSK. I should be able to > > > upgrade > > > protocols the same way. > > > > > > If RSA keys can be re-used between TLS1.2 and TLS1.3, then so > > > should > > > PSK keys. The current document specifically allows that re-use, and > > > if > > > you fear that the current document did not take cross-protocol > > > attacks > > > in mind during design, then let's fix that instead. > > > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > > different KDFs, which we don't have any analysis for > > I understand, but as I have already mentioned that argument also > applies for RSA keys which can be used e.g., for RSA encryption under > TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be used > with multiple hashes under TLS1.2 while only one under TLS1.3. > TLS 1.3 did not enforce protocol separation for that ugly scenario, so > I wouldn't expect the treatment of PSKs differently. > I will let Karthik speak for himself, but I believe we do in fact have analysis for these cases. -Ekr > Said that, I want to clarify that I wouldn't necessarily object to an > improvement the situation for externally established PSKs. The issue I > see is that TLS1.3 already gives a "good enough" solution with re-using > the key, and I'm afraid we're going to have interoperation issues if > some implementations move to universal psks and some do not, defeating > the purpose of a standard. > > regards, > Nikos > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote: > > > > > This is somewhat timely, as if we do want to introduce a > > restriction, > > > it > > > would ideally be in the form of some text in the TLS 1.3 > > > specification, > > > which is very nearly done. > > > > > > It would be good to hear more opinions on this question, > > particularly > > > from those who have worked on the formal verification directly. > > > > > > If I can attempt to summarize some discussion that occurred in > > the > > > mic > > > line today, Hannes was surprised that we would care, likening > > this > > > case > > > to the regular version negotiation, where we are happy to use the > > > same > > > certificate to sign messages for both TLS 1.2 and 1.3. David > > > Benjamin > > > points out that we explicitly go to the trouble of putting 64 > > bytes > > > of > > > 0x20 padding at the front of the content that gets signed for > > > CertificateVerify, to enforce separation between the TLS > > versions. > > > > > > My own personal opinion is that we should enforce a domain > > separation > > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's > > "Universal > > > PSKs" > > > proposal seems like a potential mechanism by which to do so > > without > > > doubling the provisioning needs. > > > > I think the same rules should apply for PSK and RSA/ECDSA/EdDSA > > keys. > > There is no inherent difference between the two keys types. I could > > have deployed TLS with PKI or TLS with PSK. I should be able to > > upgrade > > protocols the same way. > > > > If RSA keys can be re-used between TLS1.2 and TLS1.3, then so > > should > > PSK keys. The current document specifically allows that re-use, and > > if > > you fear that the current document did not take cross-protocol > > attacks > > in mind during design, then let's fix that instead. > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > different KDFs, which we don't have any analysis for I understand, but as I have already mentioned that argument also applies for RSA keys which can be used e.g., for RSA encryption under TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be used with multiple hashes under TLS1.2 while only one under TLS1.3. TLS 1.3 did not enforce protocol separation for that ugly scenario, so I wouldn't expect the treatment of PSKs differently. Said that, I want to clarify that I wouldn't necessarily object to an improvement the situation for externally established PSKs. The issue I see is that TLS1.3 already gives a "good enough" solution with re-using the key, and I'm afraid we're going to have interoperation issues if some implementations move to universal psks and some do not, defeating the purpose of a standard. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Fri, Jul 20, 2018 at 3:43 AM, Ilari Liusvaara wrote: > On Fri, Jul 20, 2018 at 10:43:48AM +0100, Matt Caswell wrote: > > > > > > On 20/07/18 10:38, Eric Rescorla wrote: > > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > > > different KDFs, which we don't have any analysis for and which the TLS > > > 1.3 document prohibits. > > > > Can you supply the reference for that prohibition? > > > > Section 'Pre-Shared Key Extension'. In practicular, the paragraph > starting "Each PSK is associated with a single Hash algorithm." That > one prohibits using PSK associated with a hash with another hash. > However, I did not find prohibition of using PSKs from prior versions > of TLS using SHA-256 as the associated hash (as that is the default). > Right. There's no such text. However, the TLS 1.2 SHA-256 KDF isn't HKDF (and of course the TLS 1.0 KDF isn't even SHA-256), so we're kind of in an unclear area. -Ekr > > -Ilari > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Fri, Jul 20, 2018 at 10:43:48AM +0100, Matt Caswell wrote: > > > On 20/07/18 10:38, Eric Rescorla wrote: > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > > different KDFs, which we don't have any analysis for and which the TLS > > 1.3 document prohibits. > > Can you supply the reference for that prohibition? > Section 'Pre-Shared Key Extension'. In practicular, the paragraph starting "Each PSK is associated with a single Hash algorithm." That one prohibits using PSK associated with a hash with another hash. However, I did not find prohibition of using PSKs from prior versions of TLS using SHA-256 as the associated hash (as that is the default). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On 20/07/18 10:38, Eric Rescorla wrote: > The issue is not cross-protocol attacks; it's the reuse of PSKs with > different KDFs, which we don't have any analysis for and which the TLS > 1.3 document prohibits. Can you supply the reference for that prohibition? Thanks Matt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Fri, Jul 20, 2018 at 12:29 AM, Nikos Mavrogiannopoulos wrote: > On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote: > > Hi all, > > > > As I mentioned at the mic today, there is a question that has been > > raised about whether it's wise to reuse an existing (TLS 1.2) PSK > > directly in the TLS 1.3 key ladder. At a high level, the reason why > > one > > might want to restrict this is that the security proofs for TLS 1.3 > > rely > > on the pre-shared key being only used with a single key-derivation > > function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different > > key-derivation function, so formally the proofs do not hold. We > > don't > > currently know of a specifc attack against such reuse, of course, but > > perhaps it is prudent to restrict our usage to adhere to the verified > > scenarios. > > > > This is somewhat timely, as if we do want to introduce a restriction, > > it > > would ideally be in the form of some text in the TLS 1.3 > > specification, > > which is very nearly done. > > > > It would be good to hear more opinions on this question, particularly > > from those who have worked on the formal verification directly. > > > > If I can attempt to summarize some discussion that occurred in the > > mic > > line today, Hannes was surprised that we would care, likening this > > case > > to the regular version negotiation, where we are happy to use the > > same > > certificate to sign messages for both TLS 1.2 and 1.3. David > > Benjamin > > points out that we explicitly go to the trouble of putting 64 bytes > > of > > 0x20 padding at the front of the content that gets signed for > > CertificateVerify, to enforce separation between the TLS versions. > > > > My own personal opinion is that we should enforce a domain separation > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal > > PSKs" > > proposal seems like a potential mechanism by which to do so without > > doubling the provisioning needs. > > I think the same rules should apply for PSK and RSA/ECDSA/EdDSA keys. > There is no inherent difference between the two keys types. I could > have deployed TLS with PKI or TLS with PSK. I should be able to upgrade > protocols the same way. > > If RSA keys can be re-used between TLS1.2 and TLS1.3, then so should > PSK keys. The current document specifically allows that re-use, and if > you fear that the current document did not take cross-protocol attacks > in mind during design, then let's fix that instead. > The issue is not cross-protocol attacks; it's the reuse of PSKs with different KDFs, which we don't have any analysis for and which the TLS 1.3 document prohibits. -Ekr > regards, > Nikos > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Editorial Errata Reported] RFC2712 (5432)
The following errata report has been submitted for RFC2712,
"Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)".
--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5432
--
Type: Editorial
Reported by: Eugene Adell
Section: Appendix
Original Text
-
Corrected Text
--
Appendix
RFC 2712 introduces new cipher suites values, starting with the
cipher value { 0x00, 0x1E }.
This cipher value was earlier known as a Fortezza cipher suite,
and this could lead to a conflict.
Notes
-
Errata 5409 was rejected and I was suggested to post another one at this place.
RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer Security) in
its Draft 01 version introduces new cipher suites values, among them three are
colliding with the Fortezza cipher suites. The Draft 02 version partially
corrects that, by shifting all of the Kerberos cipher suites values by two.
This omission of the third Fortezza cipher suite has never been corrected, and
this remains in the same state in the final RFC 2712. As a result, the cipher
suite value { 0x00, 0x1E } is now officially known as a Kerberos one.
Although not documented themselves by any RFC, the two non conflicting Fortezza
cipher suites are mentionned in the same note in the TLS protocol RFC (2246,
4346, 5246). This gives an explanation on how the Kerberos cipher suite values
were chosen.
Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.
--
RFC2712 (draft-ietf-tls-kerb-cipher-suites-04)
--
Title : Addition of Kerberos Cipher Suites to Transport Layer
Security (TLS)
Publication Date: October 1999
Author(s) : A. Medvinsky, M. Hur
Category: PROPOSED STANDARD
Source : Transport Layer Security
Area: Security
Stream : IETF
Verifying Party : IESG
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3
On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote: > Hi all, > > As I mentioned at the mic today, there is a question that has been > raised about whether it's wise to reuse an existing (TLS 1.2) PSK > directly in the TLS 1.3 key ladder. At a high level, the reason why > one > might want to restrict this is that the security proofs for TLS 1.3 > rely > on the pre-shared key being only used with a single key-derivation > function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different > key-derivation function, so formally the proofs do not hold. We > don't > currently know of a specifc attack against such reuse, of course, but > perhaps it is prudent to restrict our usage to adhere to the verified > scenarios. > > This is somewhat timely, as if we do want to introduce a restriction, > it > would ideally be in the form of some text in the TLS 1.3 > specification, > which is very nearly done. > > It would be good to hear more opinions on this question, particularly > from those who have worked on the formal verification directly. > > If I can attempt to summarize some discussion that occurred in the > mic > line today, Hannes was surprised that we would care, likening this > case > to the regular version negotiation, where we are happy to use the > same > certificate to sign messages for both TLS 1.2 and 1.3. David > Benjamin > points out that we explicitly go to the trouble of putting 64 bytes > of > 0x20 padding at the front of the content that gets signed for > CertificateVerify, to enforce separation between the TLS versions. > > My own personal opinion is that we should enforce a domain separation > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal > PSKs" > proposal seems like a potential mechanism by which to do so without > doubling the provisioning needs. I think the same rules should apply for PSK and RSA/ECDSA/EdDSA keys. There is no inherent difference between the two keys types. I could have deployed TLS with PKI or TLS with PSK. I should be able to upgrade protocols the same way. If RSA keys can be re-used between TLS1.2 and TLS1.3, then so should PSK keys. The current document specifically allows that re-use, and if you fear that the current document did not take cross-protocol attacks in mind during design, then let's fix that instead. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
