Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
The document has been approved for publication and the outstanding reference will be added in the RFC editor process during Auth48. Thank you all for your work on this protocol. Best regards, Kathleen On Tue, Mar 20, 2018 at 5:21 PM, Eric Rescorla wrote: > > > On Tue, Mar 20, 2018 at 7:42 PM, Hubert Kario wrote: >> >> On Monday, 19 March 2018 14:38:05 CET Eric Rescorla wrote: >> > On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos >> > >> > >> > wrote: >> > > On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote: >> > > > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote: >> > > > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote: >> > > > > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote: >> > > > > > ... >> > > > > > >> > > > > > > we do not have a reliable mechanism of differentiating between >> > > > > > > external and >> > > > > > > resumption PSKs while parsing Client Hello >> > > > > > >> > > > > > Well, a valid external PSK (identity) the server will of course >> > > > > > recognize, and we have a SHOULD-level requirement that the >> > > > > > obfuscated_ticket_age is zero for external PSKs. I haven't >> > > > > > gotten >> > > > > > to think through whether there is still potential for >> > > > > > information >> > > > > > leakage about external PSK identities, but it seems like there >> > > > > > would >> > > > > > not be, provided that the server prefers resumption to external- >> > > > > > PSK >> > > > > > full handshakes. >> > > > > >> > > > > I am concerned with the privacy issues linked to these "external >> > > > > PSK >> > > > > identities". If a system is set so that clients use static PSK >> > > > > identities, then the identity is an identifier and the client's >> > > > > movements and connections can be tracked. I don't think privacy is >> > > > > improved if we make it easy to differentiate external identities >> > > > > from >> > > > > resumption tickets. >> > > > >> > > > Oh, of course, the privacy considerations of the current external >> > > > PSK scheme are terrible! This follows naturally from external PSKs >> > > > having not really been a first-class citizen while we were designing >> > > > things; we stuffed resumption PSKs together with external PSKs for >> > > > the convenience of having them use the same binder construct and >> > > > only needing to have one extension at the end of the ClientHello. >> > > > Resumption flows get single-use tickets for privacy preservation, >> > > > and external PSKs get infinite use and a gigantic correlation >> > > > channel. >> > > >> > > I agree. >> > > >> > > > > If you want to use PSK with some level of privacy, you might adopt >> > > > > a >> > > > > different setup. For example, servers could provision the clients >> > > > > with a >> > > > > set of single-use external PSK identities. But then, that looks a >> > > > > lot >> > > > > like resumption. Or, clients could generate single-use external >> > > > > PSK >> > > > > identities by encrypting their long term identity and a nonce with >> > > > > the >> > > > > public key of the server, a design which of course has its own set >> > > > > of >> > > > > issues. >> > > > >> > > > But, as you note, this is something of an open problem for how to do >> > > > well, and this document is already approved by the IESG. (It's also >> > > > not entirely clear that the TLS WG would be the best place to design >> > > > this sort of scheme, though of course it could choose to do so.) >> > > > >> > > > So to me the open question is whether we consider enumeration of >> > > > external PSK identifiers to be something we can address reasonably >> > > > at this stage of the document's lifecycle at all. (I also note that >> > > > the presence of a CVE number for a similar issue does not >> > > > necessarily mean anything -- CVE assignments can occur for >> > > > situations with no actual security impact and/or against the wishes >> > > > of the software authors.) I don't think anyone has proposed a >> > > > minimal change that would close the enumeration channel, and given >> > > > that external PSKs already have bad privacy properties, it seems >> > > > like we may just have to accept this state of affairs for this >> > > > document. >> > > >> > > That's a good general remark, but not really the case for the >> > > vulnerabilities that Hubert pointed out. >> > > >> > > > Hubert also says: >> > > > >> > > > % so there's no reliable way to say that, yes, this identity is or >> > > > is >> > > > not a >> > > > % resumption ticket, if I can't decrypt it >> > > > >> > > > Mostly. External PSKs are established out of band, and that >> > > > provisioning process *could* include knowledge that the >> > > > obfuscated_ticket_age would always be zero when those PSKs are in >> > > > use, and that would be reliable for those specific parties. >> > > >> > > I believe that this can happen in an interoperable way if the protocol >> > > mandates it (which is not the case n
[TLS] Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)
The IESG has approved the following document: - 'The Transport Layer Security (TLS) Protocol Version 1.3' (draft-ietf-tls-tls13-28.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ Technical Summary This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. Working Group Summary The document is the work product of the members of the TLS WG. There is strong consensus in the working group for this document. The area that was most controversial was around the inclusion of a 0-RTT mode that has different security properties than the rest of TLS. s1.3 lists the major differences from TLS1.2, as agreed by the contributors; we do not think that the RFC needs to list the changes that occurred between each draft. The draft has had 3 WGLCs to address various issues and the chairs assessment was fair in each of these discussions. At this point there are no known outstanding issue. While I personally do not agree with inclusion of 0-RTT because there are bound to be successful attacks against the mitigations in the future, I do agree with the chair's assessment of the WG consensus and am pleased with the additional text on mitigating the associated risks with 0-RTT. Document Quality There are over 10 interoperable implementations of the protocol from different sources written in different languages. The major web browser vendors and TLS libraries vendors have draft implementations or have indicated they will support the protocol in the future. In addition to having extensive review in the TLS working group, the protocol has received unprecedented security review by the academic community. Several TRON (TLS Ready or Not) conferences were held with academic community to give them a chance to present their findings for TLS. This has resulted in improvements to the protocol. There was also much consideration and discussion around any contentious points, resolved through polls and working group last calls. Please note that ID-nits complains about the obsoleted/ updated RFCs not being listed in the abstract. This is intentional because the abstract is now a concise and comprehensive overview and is free form citations, as per RFC7322. Personnel The Document Shepherd is Sean Turner. The responsible AD is Kathleen Moriarty. The IANA Expert(s) for the registries in this document are Yoav Nir , Rich Salz , and Nick Sullivan . IANA Note This document requests the creation of the TLS SignatureScheme Registry with values assigned via Specification Required [RFC8126]. This document requests the reference for several registries be updated to point to this document. The registries include: - TLS Cipher Suite Registry, updated via via Specification Required [RFC8126] - TLS ContentType Registry, future values allocated via Standards Action [RFC8126] - TLS Alert Registry, future values allocated via Standards Action [RFC8126] - TLS HandshakeType Registry, future values allocated via Standards Action [RFC8126] - TLS ExtensionType Registry, the policy is changed in ietf-tls-iana-registry-updates and this will be reflected in version 25 of the draft RFC Editor Note Please ensure a reference is added prior to final publication for the text added in section E.6. PSK Identity Exposure of draft-ietf-tls-tls13 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Eric Rescorla's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
Eric Rescorla has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ -- COMMENT: -- Thanks for handling my DISCUSS points. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] proposed text for draft-ietf-tls-dnssec-chain-extension-06
I think the below change would address my issue, without stepping on the things people brought up today (other then suggesting, not mandating, to send proof of non-existence when halting TLSA support in the zone) Paul diff --git a/draft-ietf-tls-dnssec-chain-extension-07.xml b/draft-ietf-tls-dnssec-chain-extension-07.xml index 333d2fc..0701b22 100644 --- a/draft-ietf-tls-dnssec-chain-extension-07.xml +++ b/draft-ietf-tls-dnssec-chain-extension-07.xml @@ -508,6 +508,15 @@ does not exceed the DNS TTLs or signature validity periods of the component records in the chain. + + If the zone using TLSA records stops using TLSA records, those TLS servers + that presented TLSA records using this extension SHOULD serve the authenticated + denial of existence of TLSA records for some time so their deployment remains + distinguishable from an attack. Ending the use of this extension SHOULD NOT be + done at the same time as changing the certificate being used on the server. This + helps clients from recognising that the current changed deployment is not + an attack performed using a different mis-issued PKIX certificate. + @@ -580,26 +588,14 @@ specific servers, clients could maintain a whitelist of sites where the use of this extension is forced. The client would refuse to authenticate such servers if they failed to deliver this extension. + Those clients should interpret authenticated denial of existence proofs + as valid use of this extension and continue to establish the TLS connection, + even if this connection uses a different PKIX certificate. Client applications could also employ a Trust on First Use (TOFU) like strategy, whereby they would record the fact that a server offered the extension and use that knowledge to require it for subsequent connections. - - This protocol currently provides no way for a server to prove that - it doesn't have a TLSA record. Hence absent whitelists, a client - misdirected to a server that has fraudulently acquired a public CA - issued certificate for the real server's name, could be induced to - establish a PKIX verified connection to the rogue server that precluded - DANE authentication. This could be solved by enhancing this protocol - to require that servers without TLSA records need to provide a DNSSEC - authentication chain that proves this (i.e. the chain includes NSEC or - NSEC3 records that demonstrate either the absence of the TLSA record, - or the absence of a secure delegation to the associated zone). Such an - enhancement would be impossible to deploy incrementally though since it - requires all TLS servers to support this protocol. - - ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] proposed text for draft-ietf-tls-dnssec-chain-extension-06
Speaking as an individual, as I said in the meeting, I don't think this is a helpful change. -Ekr On Wed, Mar 21, 2018 at 1:05 PM, Paul Wouters wrote: > > I think the below change would address my issue, without stepping on the > things people brought up today (other then suggesting, not mandating, > to send proof of non-existence when halting TLSA support in the zone) > > Paul > > diff --git a/draft-ietf-tls-dnssec-chain-extension-07.xml > b/draft-ietf-tls-dnssec-chain-extension-07.xml > index 333d2fc..0701b22 100644 > --- a/draft-ietf-tls-dnssec-chain-extension-07.xml > +++ b/draft-ietf-tls-dnssec-chain-extension-07.xml > @@ -508,6 +508,15 @@ >does not exceed the DNS TTLs or signature validity periods of the >component records in the chain. > > + > + If the zone using TLSA records stops using TLSA records, those TLS > servers > + that presented TLSA records using this extension SHOULD serve the > authenticated > + denial of existence of TLSA records for some time so their > deployment remains > + distinguishable from an attack. Ending the use of this extension > SHOULD NOT be > + done at the same time as changing the certificate being used on the > server. This > + helps clients from recognising that the current changed deployment > is not > + an attack performed using a different mis-issued PKIX certificate. > + > > > > @@ -580,26 +588,14 @@ >specific servers, clients could maintain a whitelist of sites where >the use of this extension is forced. The client would refuse to >authenticate such servers if they failed to deliver this extension. > + Those clients should interpret authenticated denial of existence > proofs > + as valid use of this extension and continue to establish the TLS > connection, > + even if this connection uses a different PKIX certificate. >Client applications could also employ a Trust on First Use (TOFU) > like >strategy, whereby they would record the fact that a server offered > the >extension and use that knowledge to require it for subsequent > connections. > > > - > - This protocol currently provides no way for a server to prove that > - it doesn't have a TLSA record. Hence absent whitelists, a client > - misdirected to a server that has fraudulently acquired a public CA > - issued certificate for the real server's name, could be induced to > - establish a PKIX verified connection to the rogue server that > precluded > - DANE authentication. This could be solved by enhancing this protocol > - to require that servers without TLSA records need to provide a > DNSSEC > - authentication chain that proves this (i.e. the chain includes NSEC > or > - NSEC3 records that demonstrate either the absence of the TLSA > record, > - or the absence of a secure delegation to the associated zone). Such > an > - enhancement would be impossible to deploy incrementally though > since it > - requires all TLS servers to support this protocol. > - > - > > > > > ___ > 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] Certificate-based Authentication with External PSK
Apologies to Russ, but we ran out of time today during the session. Here’s a link to presentation that got bumped: https://datatracker.ietf.org/doc/slides-101-tls-sessa-certificate-based-authentication-with-external-psk/ spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
On Tuesday, 20 March 2018 22:21:06 CET Eric Rescorla wrote: > On Tue, Mar 20, 2018 at 7:42 PM, Hubert Kario wrote: > > On Monday, 19 March 2018 14:38:05 CET Eric Rescorla wrote: > > > On Mon, Mar 19, 2018 at 1:33 PM, Nikos Mavrogiannopoulos < > > > > n...@redhat.com> > > > > > wrote: > > > > On Fri, 2018-03-16 at 14:45 -0500, Benjamin Kaduk wrote: > > > > > On Fri, Mar 16, 2018 at 09:11:32AM -0400, Christian Huitema wrote: > > > > > > On 3/15/2018 5:51 PM, Benjamin Kaduk wrote: > > > > > > > On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote: > > > > > > > ... > > > > > > > > > > > > > > > we do not have a reliable mechanism of differentiating between > > > > > > > > external and > > > > > > > > resumption PSKs while parsing Client Hello > > > > > > > > > > > > > > Well, a valid external PSK (identity) the server will of course > > > > > > > recognize, and we have a SHOULD-level requirement that the > > > > > > > obfuscated_ticket_age is zero for external PSKs. I haven't > > > > > > > gotten > > > > > > > to think through whether there is still potential for > > > > > > > information > > > > > > > leakage about external PSK identities, but it seems like there > > > > > > > would > > > > > > > not be, provided that the server prefers resumption to external- > > > > > > > PSK > > > > > > > full handshakes. > > > > > > > > > > > > I am concerned with the privacy issues linked to these "external > > > > > > PSK > > > > > > identities". If a system is set so that clients use static PSK > > > > > > identities, then the identity is an identifier and the client's > > > > > > movements and connections can be tracked. I don't think privacy is > > > > > > improved if we make it easy to differentiate external identities > > > > > > from > > > > > > resumption tickets. > > > > > > > > > > Oh, of course, the privacy considerations of the current external > > > > > PSK scheme are terrible! This follows naturally from external PSKs > > > > > having not really been a first-class citizen while we were designing > > > > > things; we stuffed resumption PSKs together with external PSKs for > > > > > the convenience of having them use the same binder construct and > > > > > only needing to have one extension at the end of the ClientHello. > > > > > Resumption flows get single-use tickets for privacy preservation, > > > > > and external PSKs get infinite use and a gigantic correlation > > > > > channel. > > > > > > > > I agree. > > > > > > > > > > If you want to use PSK with some level of privacy, you might adopt > > > > > > a > > > > > > different setup. For example, servers could provision the clients > > > > > > with a > > > > > > set of single-use external PSK identities. But then, that looks a > > > > > > lot > > > > > > like resumption. Or, clients could generate single-use external > > > > > > PSK > > > > > > identities by encrypting their long term identity and a nonce with > > > > > > the > > > > > > public key of the server, a design which of course has its own set > > > > > > of > > > > > > issues. > > > > > > > > > > But, as you note, this is something of an open problem for how to do > > > > > well, and this document is already approved by the IESG. (It's also > > > > > not entirely clear that the TLS WG would be the best place to design > > > > > this sort of scheme, though of course it could choose to do so.) > > > > > > > > > > So to me the open question is whether we consider enumeration of > > > > > external PSK identifiers to be something we can address reasonably > > > > > at this stage of the document's lifecycle at all. (I also note that > > > > > the presence of a CVE number for a similar issue does not > > > > > necessarily mean anything -- CVE assignments can occur for > > > > > situations with no actual security impact and/or against the wishes > > > > > of the software authors.) I don't think anyone has proposed a > > > > > minimal change that would close the enumeration channel, and given > > > > > that external PSKs already have bad privacy properties, it seems > > > > > like we may just have to accept this state of affairs for this > > > > > document. > > > > > > > > That's a good general remark, but not really the case for the > > > > vulnerabilities that Hubert pointed out. > > > > > > > > > Hubert also says: > > > > > > > > > > % so there's no reliable way to say that, yes, this identity is or > > > > > is > > > > > not a > > > > > % resumption ticket, if I can't decrypt it > > > > > > > > > > Mostly. External PSKs are established out of band, and that > > > > > provisioning process *could* include knowledge that the > > > > > obfuscated_ticket_age would always be zero when those PSKs are in > > > > > use, and that would be reliable for those specific parties. > > > > > > > > I believe that this can happen in an interoperable way if the protocol > > > > mandates it (which is not the case now). These specific parties may > > > > use > > > > software from different v
[TLS] I-D Action: draft-ietf-tls-dnssec-chain-extension-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : A DANE Record and DNSSEC Authentication Chain Extension for TLS Authors : Melinda Shore Richard Barnes Shumon Huque Willem Toorop Filename: draft-ietf-tls-dnssec-chain-extension-07.txt Pages : 24 Date: 2018-03-21 Abstract: This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. It is not intended to be used to validate the TLS server's address records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dnssec-chain-extension-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Alexey Melnikov's Yes on draft-ietf-tls-dnssec-chain-extension-07: (with COMMENT)
Alexey Melnikov has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ -- COMMENT: -- Now that TLS 1.3 is approved for publication, I think adding a Normative Reference to TLS 1.3 is no brainer. I am clearing my DISCUSS on the assumption that this would be fixed before publication of the RFC. 1) TLS 1.3 needs to be a normative reference, but it is not even listed in References. 2) The first mention of NSEC3 need a normative reference. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Protocol Action: 'A DANE Record and DNSSEC Authentication Chain Extension for TLS' to Proposed Standard (draft-ietf-tls-dnssec-chain-extension-07.txt)
The IESG has approved the following document: - 'A DANE Record and DNSSEC Authentication Chain Extension for TLS' (draft-ietf-tls-dnssec-chain-extension-07.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ Technical Summary This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names. Working Group Summary There was good support and no controversy on list or in meetings. Document Quality The draft has had a fair amount of review. I am not aware of implementations as it wasn't reported by the document shepherd. Personnel The document shepherd is Joseph Salowey and the responsible AD is Kathleen Moriarty. IANA Note A new value in the TLS ExtensionsType registry RFC Editor Note Please ensure a normative reference is added for NSEC3 in the final publication. Please ensure Richard Barnes affiliation is corrected from Mozilla to Cisco. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
