[TLS] Future interoperability issues for HRR for new extensions; Was: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > The IESG has received a request from the Transport Layer Security WG (tls) > to consider the following document: - 'The Transport Layer Security (TLS) > Protocol Version 1.3' >as Proposed Standard Section 4.1.2 currently states that the only changes allowed to the second ClientHello message (in HelloRetryRequest case) are: - replacing key_share - removing early_data - adding cookie - updating pre_shared_key - adding, removing or changing padding What about extensions undefined now? What if in the future we have another extension like the PSK extension that needs to be updated for the second ClientHello? Do we accept that the above list is set in stone and will never change (except for new protocol versions), requiring all future extensions to also require the same extension payload for first and second ClientHello? -- 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
[TLS] Opsdir telechat review of draft-ietf-tls-record-limit-02
Reviewer: Éric Vyncke Review result: Has Nits Reviewer: Eric Vyncke Review results: has nits Hello Martin, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. The document is about an extension to TLS (record_size_limit) allowing endpoints to negotiate the maximum size of protected records. The document also deprecates a previous extension max_fragment_length. The different scenarios (whether endpoints support this option or not) as well as behavior of future versions of TLS are specified. Section 5 also describes the behavior when endpoints use the proposed and the deprecated TLS options. Nits in section 5: "MUST ignore *and* "max_fragment_length"" This is a short document and IMHO all operational issues are well documented and correct. -éric ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Future interoperability issues for HRR for new extensions; Was: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standar
On 02/21/2018 05:46 AM, Hubert Kario wrote: > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: >> The IESG has received a request from the Transport Layer Security WG (tls) >> to consider the following document: - 'The Transport Layer Security (TLS) >> Protocol Version 1.3' >>as Proposed Standard > Section 4.1.2 currently states that the only changes allowed to the second > ClientHello message (in HelloRetryRequest case) are: > - replacing key_share > - removing early_data > - adding cookie > - updating pre_shared_key > - adding, removing or changing padding > > What about extensions undefined now? What if in the future we have another > extension like the PSK extension that needs to be updated for the second > ClientHello? > > Do we accept that the above list is set in stone and will never change > (except > for new protocol versions), requiring all future extensions to also require > the same extension payload for first and second ClientHello? > It seems to me that such a hypothetical future extension could include a signaling value in the HRR to indicate that the server understands the new extension, and the semantics of the extension defined such that when the server understands the extension the client may change its value between ClientHello1 and ClientHello2. This might be slightly inefficient if the extension's information flow is only from client to server, but I think it would be a compatible way to allow an extension value to change after HRR. -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > The IESG has received a request from the Transport Layer Security WG (tls) > to consider the following document: - 'The Transport Layer Security (TLS) > Protocol Version 1.3' >as Proposed Standard The current draft states that if the server recognises an identity but is unable to verify corresponding binder, it "MUST abort the handshake" at the same time, they "SHOULD select as single PSK and validate solely the binder that corresponds to that PSK" (Page 60, draft-ietf-tls-tls13-24). That allows for trivial enumeration of externally established identities - the attacker just needs to send to the server a list of identity guesses, with random data as binders, if the server recognises any identity it will abort connection, if it doesn't, it will continue to a non-PSK handshake. Behaviour like this is generally considered a vulnerability: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229 I was wondering if the document shouldn't recommend ignoring any and all identities for which binders do not verify to prevent this kind of attack. -- 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] Future interoperability issues for HRR for new extensions; Was: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standar
On Wed, Feb 21, 2018 at 6:10 AM, Benjamin Kaduk wrote: > On 02/21/2018 05:46 AM, Hubert Kario wrote: > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > >> The IESG has received a request from the Transport Layer Security WG > (tls) > >> to consider the following document: - 'The Transport Layer Security > (TLS) > >> Protocol Version 1.3' > >>as Proposed Standard > > Section 4.1.2 currently states that the only changes allowed to the > second > > ClientHello message (in HelloRetryRequest case) are: > > - replacing key_share > > - removing early_data > > - adding cookie > > - updating pre_shared_key > > - adding, removing or changing padding > > > > What about extensions undefined now? What if in the future we have > another > > extension like the PSK extension that needs to be updated for the second > > ClientHello? > > > > Do we accept that the above list is set in stone and will never change > (except > > for new protocol versions), requiring all future extensions to also > require > > the same extension payload for first and second ClientHello? > > > > It seems to me that such a hypothetical future extension could include a > signaling value in the HRR to indicate that the server understands the > new extension, and the semantics of the extension defined such that when > the server understands the extension the client may change its value > between ClientHello1 and ClientHello2. > > This might be slightly inefficient if the extension's information flow > is only from client to server, but I think it would be a compatible way > to allow an extension value to change after HRR. > Yes. Also, there's not really any good reason to change an extension that is not mentioned in HRR. -Ekr > -Ben > > ___ > 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] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrote: > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > > The IESG has received a request from the Transport Layer Security WG > (tls) > > to consider the following document: - 'The Transport Layer Security (TLS) > > Protocol Version 1.3' > >as Proposed Standard > > The current draft states that if the server recognises an identity but is > unable to verify corresponding binder, it "MUST abort the handshake" > Which text are you referring to here? -Ekr at the same time, they "SHOULD select as single PSK and validate solely the > binder that corresponds to that PSK" > (Page 60, draft-ietf-tls-tls13-24). > > That allows for trivial enumeration of externally established identities - > the > attacker just needs to send to the server a list of identity guesses, with > random data as binders, if the server recognises any identity it will abort > connection, if it doesn't, it will continue to a non-PSK handshake. > > Behaviour like this is generally considered a vulnerability: > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229 > > I was wondering if the document shouldn't recommend ignoring any and all > identities for which binders do not verify to prevent this kind of attack. > -- > 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 > ___ > 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] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
(fixing missed i...@ietf.org) On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > The IESG has received a request from the Transport Layer Security WG (tls) > to consider the following document: - 'The Transport Layer Security (TLS) > Protocol Version 1.3' >as Proposed Standard The current draft states that if the server recognises an identity but is unable to verify corresponding binder, it "MUST abort the handshake" at the same time, they "SHOULD select as single PSK and validate solely the binder that corresponds to that PSK" (Page 60, draft-ietf-tls-tls13-24). That allows for trivial enumeration of externally established identities - the attacker just needs to send to the server a list of identity guesses, with random data as binders, if the server recognises any identity it will abort connection, if it doesn't, it will continue to a non-PSK handshake. Behaviour like this is generally considered a vulnerability: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229 I was wondering if the document shouldn't recommend ignoring any and all identities for which binders do not verify to prevent this kind of attack. -- 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] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote: > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrote: > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > > > The IESG has received a request from the Transport Layer Security WG > > > > (tls) > > > > > to consider the following document: - 'The Transport Layer Security > > > (TLS) > > > Protocol Version 1.3' > > > > > >as Proposed Standard > > > > The current draft states that if the server recognises an identity but is > > unable to verify corresponding binder, it "MUST abort the handshake" > > Which text are you referring to here? Section 4.2.11: Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see Section 4.2.11.2 below). If this value is not present or does not validate, the server MUST abort the handshake. Servers SHOULD NOT attempt to validate multiple binders; rather they SHOULD select a single PSK and validate solely the binder that corresponds to that PSK. > -Ekr > > at the same time, they "SHOULD select as single PSK and validate solely the > > > binder that corresponds to that PSK" > > (Page 60, draft-ietf-tls-tls13-24). > > > > That allows for trivial enumeration of externally established identities - > > the > > attacker just needs to send to the server a list of identity guesses, with > > random data as binders, if the server recognises any identity it will > > abort > > connection, if it doesn't, it will continue to a non-PSK handshake. > > > > Behaviour like this is generally considered a vulnerability: > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190 > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229 > > > > I was wondering if the document shouldn't recommend ignoring any and all > > identities for which binders do not verify to prevent this kind of attack. > > -- > > 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 > > ___ > > 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] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
i think your general point is sound here, but I'll nitpick the statement that "if the server recognises an identity but is unable to verify corresponding binder". 1. The server only picks one identity so you if you send A, B, and C and you get an abort, you don't know if it recognized one or all. 2. The server can *recognize* the identity but ignore it (say it's a ticket that's too old) With that said, I think it would probably be safe to say you must ignore an identity where the binder doesn't validate, but I'd like to hear from cryptographers on this one. Thanks, -Ekr On Wed, Feb 21, 2018 at 6:26 AM, Hubert Kario wrote: > On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote: > > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrote: > > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > > > > The IESG has received a request from the Transport Layer Security WG > > > > > > (tls) > > > > > > > to consider the following document: - 'The Transport Layer Security > > > > (TLS) > > > > Protocol Version 1.3' > > > > > > > >as Proposed Standard > > > > > > The current draft states that if the server recognises an identity but > is > > > unable to verify corresponding binder, it "MUST abort the handshake" > > > > Which text are you referring to here? > > Section 4.2.11: > >Prior to accepting PSK key establishment, the server MUST validate >the corresponding binder value (see Section 4.2.11.2 below). If this >value is not present or does not validate, the server MUST abort the >handshake. Servers SHOULD NOT attempt to validate multiple binders; >rather they SHOULD select a single PSK and validate solely the binder >that corresponds to that PSK. > > > -Ekr > > > > at the same time, they "SHOULD select as single PSK and validate solely > the > > > > > binder that corresponds to that PSK" > > > (Page 60, draft-ietf-tls-tls13-24). > > > > > > That allows for trivial enumeration of externally established > identities - > > > the > > > attacker just needs to send to the server a list of identity guesses, > with > > > random data as binders, if the server recognises any identity it will > > > abort > > > connection, if it doesn't, it will continue to a non-PSK handshake. > > > > > > Behaviour like this is generally considered a vulnerability: > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190 > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229 > > > > > > I was wondering if the document shouldn't recommend ignoring any and > all > > > identities for which binders do not verify to prevent this kind of > attack. > > > -- > > > 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 > > > ___ > > > 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 > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
Sorry for my belated follow-up. Was temporarily overwhelmed by the day job .. On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla wrote: > On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote: > > > > IMPORTANT: I'm not sure that this is actually sufficient to allow an > > > independent implementation without referring to the other documents. I > > > mean, I think I pretty clearly can't validate this chain from the > > > above. > > > > We could add an explicit reference here to the DNS protocol document(s) > > and sections within them that define the canonical form of domain > > names (RFC 4034, Section 6 probably is the best reference), or even > > excerpt the relevant text from that document. Would this satisfy your > > concern? > > > > Well, and remove your text about it being possible to implement solely from > this > document. Yes, I agree, we need to remove that. > It's not the algorithm. I don't believe this document is sufficient to > parse the > structure. Okay, got it. For people that have already implemented this, I think there has been an implicit understanding that the format of the chain data is a sequence of concatenated wire format RRs exactly as they appear in a DNS message section (with one injunction against doing DNS name compression). I'll write some text to make this more explicit and describe the format in more detail with references to the appropriate DNS specs. This is also the format that is readily generated and consumed by some DNS libraries and the Intro section of this document has the following assumption: "... (assuming that the data will be prepared and consumed by a DNS-specific library) ..." > > Similarly, although I think this is enough to break apart the > > > RRSETs into RRs, it doesn't tell me how to separate the RRSETs from > > > each other. I think you need to either make this a lot more complete > > > or alternately stop saying it's sufficient. > > > > We can add some text about this. Basically the client would scan the chain > > reading RRs and group adjacent RRs that share the same RR name, type, and > > class into a distinct RRset. > > > > I'd have to review your text to know if it was sufficient. Ok. I'm working on text for this .. > > > > * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation mechanisms > > need to be consulted and honored. > > > > Well, neither of these modes is useful here, as an attacker will simply > ignore the > extension. Just to confirm, I assume the attacker here is an entity attempting to impersonate the TLS server (with presumably valid PKIX credentials). If so, yes it can trivially ignore the extension, but this is the case for any DANE usage mode (not just the PKIX constraining ones). As discussed in Section 8, the protocol as currently specified really only allows opportunistic DANE authentication, unless some mechanism external to TLS is employed to mandate DANE usage. (The protocol could be extended to require TLS servers to also provide a DNSSEC proof that they don't have a signed TLSA record, but that could only be deployed in a TLS application system where all servers supported this extension). > On your last case, "cert validates but DANE does not", I assume > > you mean the cert validates via PKIX but not DANE? I'm not sure this > > is explicitly discussed in any other DANE document but presumably > > if DANE is being used, DANE must validate. > > > > Why would that be so? This only is useful in DANE-EE and DANE-TA modes in > the first place, and so there is a possibilityt aht PKIX is valid. I think Viktor's earlier reply to this thread goes into detail about possible client behaviors here and what we might recommend (which seems reasonable to me). I'll follow-up there. > > 3.1. Protocol, TLS 1.2 > > > You should probably provide some guidance about whether the server > > should still > > > provide the whole X.509 chain to the client. I believe with these > > semantics, > > > the server cannot tell which DANE mode the client wants and therefore > > has to > > > provide the entire chain. > > > > Sure, we can elaborate. > > > > The DANE mode to be used is advertised by the server in its TLSA record(s), > > so the server already knows whether it needs to return the X.509 chain. > > If the TLSA RRset has only DANE-EE, then only the end-entity certificate > > needs to be returned. If DANE-TA, then only the chain from the TA cert to > > the > > EE needs to be returned. If using the PKIX modes, then yes, the entire > > X.509 > > chain has to be sent. > > > > The problem is that the client is the decider about what it wants to > accept, not > the server. My comment was about what DANE mode choices the server is offering to the client. Certainly, the client can decide whether it wants to use DANE or not, and whether it wants to fallback to PKIX. The protocol should probably not be proscriptive here, and allow different TLS applications (or configurations of such applications) to make choices. But maybe there
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni wrote: > > > Summary as I see it: > > * Mandatory DANE: > MUST Refuse absence of TLSA RRs or failure > of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs > are cache and the server does not present the extension. > > * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1) > if caching replies, and SHOULD attempt to refresh cache before > expiration to reduce opportunity for downgrades. Non-caching > clients don't really gain security by refusing valid PKIX on > DANE failure, and MAY choose to continue. > This seems reasonable to me too. Shumon ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson wrote: > On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty > wrote: > > What's the behavior when the middlebox is a proxy, let's say existing > > a managed network? I presume from from section 3.1 that this > > negotiation doesn't work in that instance unless sites configured for > > this are not subject to the proxy as is often done for financial site > > access from corporate networks. It would be good to know if it does > > work and that is addressed with the text Mirja calls out for her #1 > > question. Having this clarified could be helpful. > > If there is a MitM, then this extension simply isn't negotiated. > That's pretty well understood. I don't see why that requires special > mention. > Yeah, I agree Martin .. this is the same as with any other extension. Shumon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
On Wed, Feb 21, 2018 at 11:00 AM, Shumon Huque wrote: > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson > wrote: >> >> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty >> wrote: >> > What's the behavior when the middlebox is a proxy, let's say existing >> > a managed network? I presume from from section 3.1 that this >> > negotiation doesn't work in that instance unless sites configured for >> > this are not subject to the proxy as is often done for financial site >> > access from corporate networks. It would be good to know if it does >> > work and that is addressed with the text Mirja calls out for her #1 >> > question. Having this clarified could be helpful. >> >> If there is a MitM, then this extension simply isn't negotiated. >> That's pretty well understood. I don't see why that requires special >> mention. > > > Yeah, I agree Martin .. this is the same as with any other extension. OK, I think it is clear in the discussion with 1.2, but wasn't sure if it was clear enough elsewhere and figured it was best to ask. > > Shumon. > -- Best regards, Kathleen ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque wrote: > On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov > wrote: > >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-tls-dnssec-chain-extension-06: Discuss >> >> -- >> DISCUSS: >> -- >> >> I think this is a useful document and I will ballot Yes once my small >> issues are resolved: >> >> 1) In 3.4: >> >>The first RRset in the chain MUST contain the TLSA record set being >>presented. However, if the owner name of the TLSA record set is an >>alias (CNAME or DNAME), then it MUST be preceded by the chain of >>alias records needed to resolve it. DNAME chains should omit >> >> SHOULD? What are the implications if this is not followed? >> > > Ok. I guess we need the upper case word here, yes. > > Implication: If the synthesized CNAME records are included in the chain > then the client will have to ignore them (they aren't signed and thus > can't be > validated) - the signed DNAME record is sufficient for the client to > securely > validate the mapping and continue processing. > > It might make things simpler to just make this a MUST. I would guess this > would not raise any objections from the working group. > A quick follow-up on this. I think we just keep this as a SHOULD. I looked at what an existing DNS library implementation does, and it includes the synthesized CNAME. It's easy enough for the client to just ignore it when validating the chain. Shumon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
> On Feb 21, 2018, at 10:57 AM, Shumon Huque wrote: > > On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni > wrote: > > Summary as I see it: > > * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure > of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs > are cache and the server does not present the extension. Just to clarify "failure of PKIX-TA(0) and PKIX-EE(1)" is intended to consider failure to satisfy the usual PKIX verification requirements for these certificate usages. Naturally, mandatory DANE can also be satisfied via matching DANE-TA(2) or DANE-EE(3) or fail via broken DANE-TA(2) or DANE-EE(3). > > * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1) > if caching replies, and SHOULD attempt to refresh cache before > expiration to reduce opportunity for downgrades. Non-caching > clients don't really gain security by refusing valid PKIX on > DANE failure, and MAY choose to continue. > > This seems reasonable to me too. Here too, a client MAY choose to fail when the presented certificate chain fails all the associated (cached or freshly obtained) DANE TLSA records whether these are PKIX-TA/EE, DANE-TA/EE or some mixture. The restricted focus on just PKIX-TA/PKIX-EE is not needed. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Wed, Feb 21, 2018 at 12:05 PM, Viktor Dukhovni wrote: > > > > On Feb 21, 2018, at 10:57 AM, Shumon Huque wrote: > > > > On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni > wrote: > > > > Summary as I see it: > > > > * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure > > of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs > > are cache and the server does not present the extension. > > Just to clarify "failure of PKIX-TA(0) and PKIX-EE(1)" is intended to > consider failure to satisfy the usual PKIX verification requirements > for these certificate usages. Naturally, mandatory DANE can also be > satisfied via matching DANE-TA(2) or DANE-EE(3) or fail via broken > > DANE-TA(2) or DANE-EE(3). > Yup, I understood, but thanks for clarifying ... > > > > * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1) > > if caching replies, and SHOULD attempt to refresh cache before > > expiration to reduce opportunity for downgrades. Non-caching > > clients don't really gain security by refusing valid PKIX on > > DANE failure, and MAY choose to continue. > > > > This seems reasonable to me too. > > Here too, a client MAY choose to fail when the presented certificate > chain fails all the associated (cached or freshly obtained) DANE TLSA > records whether these are PKIX-TA/EE, DANE-TA/EE or some mixture. > The restricted focus on just PKIX-TA/PKIX-EE is not needed. > Yes, no need to restrict such a policy choice to only the PKIX-* modes. Shumon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque wrote: > Sorry for my belated follow-up. Was temporarily overwhelmed by the > day job .. > > > On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla wrote: > > On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote: > > > > > > IMPORTANT: I'm not sure that this is actually sufficient to allow an > > > > independent implementation without referring to the other documents. > I > > > > mean, I think I pretty clearly can't validate this chain from the > > > > above. > > > > > > We could add an explicit reference here to the DNS protocol document(s) > > > and sections within them that define the canonical form of domain > > > names (RFC 4034, Section 6 probably is the best reference), or even > > > excerpt the relevant text from that document. Would this satisfy your > > > concern? > > > > > > > Well, and remove your text about it being possible to implement solely > from > > this > > document. > > Yes, I agree, we need to remove that. > > > > It's not the algorithm. I don't believe this document is sufficient to > > parse the > > structure. > > > Okay, got it. For people that have already implemented this, I think > there has been an implicit understanding that the format of the chain > data is a sequence of concatenated wire format RRs exactly as they appear > in a DNS message section (with one injunction against doing DNS name > compression). I'll write some text to make this more explicit and describe > the format in more detail with references to the appropriate DNS specs. > > This is also the format that is readily generated and consumed by some > DNS libraries and the Intro section of this document has the following > assumption: "... (assuming that the data will be prepared and consumed > by a DNS-specific library) ..." > Sure. I'm not arguing that this is a bad format. It's just a matter of making clear to the user what they have to do to parse it. > > > * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation > mechanisms > > > need to be consulted and honored. > > > > > > > Well, neither of these modes is useful here, as an attacker will simply > > ignore the > > extension. > > Just to confirm, I assume the attacker here is an entity attempting > to impersonate the TLS server (with presumably valid PKIX credentials). > If so, yes it can trivially ignore the extension, but this is the case > for any DANE usage mode (not just the PKIX constraining ones). > Agreed. It's just a less useful form of attack for the DANE modes where you are authenticating with DANE only, as it's basically just a form of DOS. > As discussed in Section 8, the protocol as currently specified really > only allows opportunistic DANE authentication, unless some mechanism > external to TLS is employed to mandate DANE usage. (The protocol could > be extended to require TLS servers to also provide a DNSSEC proof that > they don't have a signed TLSA record, but that could only be deployed > in a TLS application system where all servers supported this extension). > I agree. > > 3.1. Protocol, TLS 1.2 > > > > You should probably provide some guidance about whether the server > > > should still > > > > provide the whole X.509 chain to the client. I believe with these > > > semantics, > > > > the server cannot tell which DANE mode the client wants and therefore > > > has to > > > > provide the entire chain. > > > > > > Sure, we can elaborate. > > > > > > The DANE mode to be used is advertised by the server in its TLSA > record(s), > > > so the server already knows whether it needs to return the X.509 chain. > > > If the TLSA RRset has only DANE-EE, then only the end-entity > certificate > > > needs to be returned. If DANE-TA, then only the chain from the TA cert > to > > > the > > > EE needs to be returned. If using the PKIX modes, then yes, the entire > > > X.509 > > > chain has to be sent. > > > > > > > The problem is that the client is the decider about what it wants to > > accept, not > > the server. > > My comment was about what DANE mode choices the server is offering to > the client. Certainly, the client can decide whether it wants to use > DANE or not, and whether it wants to fallback to PKIX. The protocol > should probably not be proscriptive here, and allow different TLS > applications (or configurations of such applications) to make choices. > But maybe there are some general recommendations to be made. > > One additional comment about PKIX fallback on DANE failure: If a > server is using DANE-EE or DANE-TA, it has the ability to send back > a much shorter Certificate message - just the EE certificate for the > former, and typically a very short X.509 chain for the latter. But > this means that for fallback to PKIX, the client would have to start > a new handshake omitting the dnssec_chain extension. For efficient > fallback within the same handshake, the server would always have to > send back the full PKIX X.509 chain. Maybe that's what we need to > recommend for se
Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
> On Feb 21, 2018, at 11:00 AM, Shumon Huque wrote: > > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson > wrote: > On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty > wrote: >> What's the behavior when the middlebox is a proxy, let's say existing >> a managed network? I presume from from section 3.1 that this >> negotiation doesn't work in that instance unless sites configured for >> this are not subject to the proxy as is often done for financial site >> access from corporate networks. It would be good to know if it does >> work and that is addressed with the text Mirja calls out for her #1 >> question. Having this clarified could be helpful. > > If there is a MitM, then this extension simply isn't negotiated. > That's pretty well understood. I don't see why that requires special > mention. > > Yeah, I agree Martin .. this is the same as with any other extension. Actually, I don't think it is quite the same. This extension may be naïvely expected to provide a different peer authentication mechanism than the traditional WebPKI. Users who might expect this extension to protect them from WebPKI compromise via DANE TLSA records, need to understand that such protection only exists when DANE is enforced (mandatory) by the client. The absence of DANE TLSA records, which is downgrade-resistant when the client has access to DNSSEC authenticated denial of existence (makes its own DNSSEC lookups) is no longer downgrade- resistant when delivered via this extension if the client is willing to accept just WebPKI in the (apparent) absence of DANE TLSA records. -- Viktor. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Thu, 8 Feb 2018, Viktor Dukhovni wrote: For clients that do reject PKIX success based on DANE failure, and cache obtained TLSA records, it might have been good to recommend refreshing the TLSA records while the cached data is still valid (say the smaller of some refresh time or 50% of TTL has expired). That way, for a client that keeps communicating regularly may be (partially) protected against downgrades. Perhaps it is too late to make such a change at this stage in the document's life-cycle. Is it customary for TLS clients that do PKIX validation to check the certificate expiry for long lived TLS connections? I assumed most TLS clients verification is done at the start of the connection only and the connection is then deemed verified until it closes - irrespective of the signature lifetimes of the certificate? Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Wed, 21 Feb 2018, Shumon Huque wrote: Okay, got it. For people that have already implemented this, I think there has been an implicit understanding that the format of the chain data is a sequence of concatenated wire format RRs exactly as they appear in a DNS message section Note, I would not call it "sequence of concatenated wire format RRs", as it is simply the wireformat of a DNS message. The fact that some parts are concatenated RR's is just part of the wireformat of the DNS reply message. That is, this isn't introducing some new form of concatenated content - it is _just_ a regular DNS wire format message, and the document should not go deeper into its explanation. I noticed some discussion about the ordering of this content. I am not sure why that should be done. DNS doesn't care about the order, and neither should producers or consumers of this extension. DNS has no ordering inside its message. In pseudo code, they should simply: while(not stuck and not empty(RRlist)): stuck = True for each RR in RRlist: if validated_with_cache(RR): add_to_cache(RR) remove_from_RRlist(RR) stuck = False And then the order of RRs doesn't matter. I don't think getting unrelated DNSSEC records would be an issue. TLS has its maximum sizes for the handshake. In fact, it could allow the extension to have some useful data in the case of MX or SRV. (and could be a feature to build a nice resolver over TLS using 1 tor circuit) I'm also not sure about the talking of unsigned CNAME records from DNAME. The above pseudo code (extended with special cases) should be in some DNS library, and that library will know what records to expect unsigned which are proven by the DNAME (or wildcard) synthesis and knows when/if to add it to the validated cache. I don't think that should be explained in this RFC at all. The DNS implementation does not need to be specified in this document and it should just focus on saying that "the DNS message response is validated and upon validation the content can be considered DANE validated". Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
> On Feb 21, 2018, at 2:21 PM, Paul Wouters wrote: > >> For clients that do reject PKIX success based on DANE failure, and >> cache obtained TLSA records, it might have been good to recommend >> refreshing the TLSA records while the cached data is still valid >> (say the smaller of some refresh time or 50% of TTL has expired). >> That way, for a client that keeps communicating regularly may be >> (partially) protected against downgrades. Perhaps it is too late >> to make such a change at this stage in the document's life-cycle. > > Is it customary for TLS clients that do PKIX validation to check the > certificate expiry for long lived TLS connections? The text you're responding to is NOT about long-lived TLS connections, rather it addresses the case where the client makes repeated connections frequently enough to benefit from caching previously obtained TLSA records for verifying future connections. In that case it makes sense to "refresh" the TLSA records (include the extension in a new request) even before the previously cached data has expired. > I assumed most TLS clients verification is done at the start of the > connection only and the connection is then deemed verified until it > closes - irrespective of the signature lifetimes of the certificate? Correct, but not applicable to the topic at hand. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Wed, Feb 21, 2018 at 11:21 AM, Paul Wouters wrote: > On Thu, 8 Feb 2018, Viktor Dukhovni wrote: > > For clients that do reject PKIX success based on DANE failure, and >> cache obtained TLSA records, it might have been good to recommend >> refreshing the TLSA records while the cached data is still valid >> (say the smaller of some refresh time or 50% of TTL has expired). >> That way, for a client that keeps communicating regularly may be >> (partially) protected against downgrades. Perhaps it is too late >> to make such a change at this stage in the document's life-cycle. >> > > Is it customary for TLS clients that do PKIX validation to check the > certificate expiry for long lived TLS connections? > > I assumed most TLS clients verification is done at the start of the > connection only and the connection is then deemed verified until it > closes - irrespective of the signature lifetimes of the certificate? > To the best of my knowledge you are correct. -Ekr > > Paul > > ___ > 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] Opsdir telechat review of draft-ietf-tls-record-limit-02
Thanks Éric. https://github.com/tlswg/tls-record-limit/pull/16 fixes your nit. On Thu, Feb 22, 2018 at 12:46 AM, Éric Vyncke wrote: > Reviewer: Éric Vyncke > Review result: Has Nits > > Reviewer: Eric Vyncke > Review results: has nits > > Hello Martin, > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments > were written with the intent of improving the operational aspects of the IETF > drafts. > > The document is about an extension to TLS (record_size_limit) allowing > endpoints to negotiate the maximum size of protected records. The document > also > deprecates a previous extension max_fragment_length. > > The different scenarios (whether endpoints support this option or not) as well > as behavior of future versions of TLS are specified. Section 5 also describes > the behavior when endpoints use the proposed and the deprecated TLS options. > > Nits in section 5: "MUST ignore *and* "max_fragment_length"" > > This is a short document and IMHO all operational issues are well documented > and correct. > > -éric > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
I think that the current behavior is fine, but we might add text to suggest that identities be self-authenticating to avoid this sort of enumeration. Note that in common practice, this sort of enumeration would be over an infeasibly large space, it's only where identities are more easily enumerable that it becomes an issue (e.g., "ted" as an identity, rather than a self-encrypted session ticket) On Thu, Feb 22, 2018 at 1:31 AM, Eric Rescorla wrote: > i think your general point is sound here, but I'll nitpick the statement > that > "if the server recognises an identity but is unable to verify corresponding > binder". > > 1. The server only picks one identity so you if you send A, B, and C and you > get an abort, you don't know if it recognized one or all. > 2. The server can *recognize* the identity but ignore it (say it's a ticket > that's > too old) > > With that said, I think it would probably be safe to say you must ignore an > identity > where the binder doesn't validate, but I'd like to hear from cryptographers > on this > one. > > Thanks, > -Ekr > > > On Wed, Feb 21, 2018 at 6:26 AM, Hubert Kario wrote: >> >> On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote: >> > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrote: >> > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: >> > > > The IESG has received a request from the Transport Layer Security WG >> > > >> > > (tls) >> > > >> > > > to consider the following document: - 'The Transport Layer Security >> > > > (TLS) >> > > > Protocol Version 1.3' >> > > > >> > > >as Proposed Standard >> > > >> > > The current draft states that if the server recognises an identity but >> > > is >> > > unable to verify corresponding binder, it "MUST abort the handshake" >> > >> > Which text are you referring to here? >> >> Section 4.2.11: >> >>Prior to accepting PSK key establishment, the server MUST validate >>the corresponding binder value (see Section 4.2.11.2 below). If this >>value is not present or does not validate, the server MUST abort the >>handshake. Servers SHOULD NOT attempt to validate multiple binders; >>rather they SHOULD select a single PSK and validate solely the binder >>that corresponds to that PSK. >> >> > -Ekr >> > >> > at the same time, they "SHOULD select as single PSK and validate solely >> > the >> > >> > > binder that corresponds to that PSK" >> > > (Page 60, draft-ietf-tls-tls13-24). >> > > >> > > That allows for trivial enumeration of externally established >> > > identities - >> > > the >> > > attacker just needs to send to the server a list of identity guesses, >> > > with >> > > random data as binders, if the server recognises any identity it will >> > > abort >> > > connection, if it doesn't, it will continue to a non-PSK handshake. >> > > >> > > Behaviour like this is generally considered a vulnerability: >> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190 >> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229 >> > > >> > > I was wondering if the document shouldn't recommend ignoring any and >> > > all >> > > identities for which binders do not verify to prevent this kind of >> > > attack. >> > > -- >> > > 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 >> > > ___ >> > > 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 > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Comments on draft-ietf-tls-sni-encryption-01.txt
I have analyzed the two mechanisms proposed in the draft, with specific focus on the impact of middleboxes. Assumptions: The middlebox is deployed inline, between the client and the fronting server, and is allowed to intercept TLS sessions. The middlebox is policy-driven, and uses SNI as an input in determining whether or not to intercept the session; the policy must use the SNI of the hidden server. Mechanism #1 : Tunnel ClientHello in 0-RTT early data. (1) Mechanism #1 requires 0-RTT support, but the middlebox would not be violating the TLS 1.3 specification by not implementing 0-RTT. The middlebox intercepts all sessions destined to a specific fronting server (F); the identity of F should be public knowledge, but even if it is not, we have to assume that the middlebox has a mechanism to decide when to intercept sessions destined to F. (2) Assume that the middlebox actually supports PSK and 0-RTT, i.e. TLS intercept with PSK/0-RTT support in the session between the client and the middlebox, as well as PSK/0-RTT support in the session between the middlebox and the fronting server. The middlebox will be able to decode ClientHello#2 sent in the 0-RTT early data because the client_early_traffic_secret will be known to the middlebox. The middlebox would thus have access to the SNI of the hidden server, and would be able to evaluate policy. The middlebox would have the option to pull out of the session after sending ClientHello#2 to the fronting server (re-encrypted with the client_early_traffic_secret shared between the middlebox and the fronting server). Mechanism #2: Session ticket that can be decoded by Fronting and Hidden server. (3) Mechanism #2 relies on PSK session resumption support in the middlebox; this is not guaranteed. (4) The middlebox would not participate or interfere in any of the out-of-band channels between the fronting server and the hidden server, which implies that the middlebox will not be able to decode the session ticket generated by the hidden server - but it does not have to. The middlebox would be able to observe the encoded session ticket in the NewSessionTicket message because it intercepts the initial TLS session between the client and the hidden server (even if mechanism #1 is used for the first session). The middlebox would thus be able to extract the SNI of the hidden server from the NewSessionTicket message and build a mapping of encoded session tickets to hidden servers. TLS sessions (destined to the fronting server) that were not previously intercepted by the middlebox will use PSK identities that are not in the mapping table - the middlebox would likely force intercept of those sessions and strip the unknown PSK identities, which would result in a TLS session that terminates on the fronting server, leaving the fronting server without any knowledge of the hidden server. (5) Ignoring middleboxes, in my opinion the infrastructure required for collaboration between fronting servers and hidden servers (stateful, shared-key, public-key, or otherwise) would be a practical barrier to entry for most server administrators. --Roelof ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
