Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
Hi, On Wed, Feb 21, 2018, at 4:06 PM, Shumon Huque wrote: > 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. I think adding some text explaining this would be a good addition to the document. Best Regards, Alexey ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
When the server supports externally set PSKs that use human readable identities (or, in general, guessable identities), the current text makes it trivial to perform enumeration attack. The proposed fix was identified as conflicting with the "Client Hello Recording" security section, the severity of that conflict wasn't quantified though. Issue in detail: Problematic paragraph as it stands in draft-ietf-tls-tls13-26 (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. In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity. That means, given a server with both PSK and PKI authentication, if attacker sends multiple PSK identities with garbage binders, the server will abort the connection if and only if at least one of the identities was recognised by server. Applying the well known binary search method allows the attacker to then narrow it down to a single identity in O(log_2(n)) steps. The solution to ignore that one selected binder, and continuing the connection in case that binder does not validate (this is the version in the PR mentioned below), unfortunately doesn't solve this issue either; If the attacker is in possession of a known good PSK secret (established either through session resumption mechanism or of a less-privileged identity), it can list the known good one as the very last one in the PSK extension. If server recognises one of the identities earlier in the list it will choose no identity (as the binder didn't validate) or the known good identity if none of the previous identities were recognised. Again, applying binary search method allows the attacker to narrow the list to a single entry in just O(log_2(n)) steps. Proposed solution: in paragraph above, in description of `binders`: binders : A series of HMAC values, one for each PSK offered in the "pre_shared_keys" extension and in the same order, computed as described below. If the number of binders does not match number of identities the server MUST abort the connection with "illegal_parameter" alert. problematic paragraph after changes: Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see Section 4.2.11.2 below). If this value does not validate, the server MUST ignore the associated identity and retry selection of identity. If no identity is recognised or, for recognised identities, no binder could be validated the server MUST continue connection as if PSK key establishment wasn't attempted. In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity. Unfortunately that solution was identified as conflicting with "Client Hello Recording" section. Do we consider that conflict to be severe enough to block this change? Or should we just add more information to that security section, that it needs to deal with this kind of attack? PS: some discussion on this issue already happened in the github PR: https://github.com/tlswg/tls13-spec/pull/1167 -- 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] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Mon, 5 Mar 2018, Willem Toorop wrote: No Paul, the division in sections is irrelevant for a verifier. The only bit of information in a DNS message that is used by a verifier is the question. From the question, validation starts and the relevant records are followed and verified. But the question section is also not needed as the question can be derived from the name and port of the service, i.e. ._tcp.. TLSA The order described in the draft is both an optimization to reduce the number of times a verifier has to go over the RRs, and it makes the content easier to read (and understand) for humans too. Also, for non existence answers, DNSSEC validators (and thus also a verifier for the chain extension) simply ignore the DNS message header. Proof of non-existence can and must be derived from the set of RRs in the message body/sections too. Willem (and Shumon and Viktor) have convinced me the DNS Header and Sections are not needed. The extension already supports Denial of Existence proof b.t.w., because it is also needed for wildcard expansions (which are supported). The issue here is the requirement of the TLS server to send these records in the absence of any TLS record. This allows the clients to detect a rogue webserver cert that is valid in webPKI but not valid based on DANE. Without this commitment, the TLS extension does not really work, as it can be omitted by an attacker. 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)
Hello, Can you please provide updated text that addresses EKR's discuss while this additional discussion continues? I'd like to see if it's possible to get this wrapped up before the plenary in London. Eliminating discuss points and resolving this additional issue are required for that. If this does not get wrapped up before then, it is likely the draft will have to go on another IESG telechat with Ben as AD, which is fine if that's needed, but better to avoid. Thank you, Kathleen On Mon, Mar 12, 2018 at 2:29 PM, Paul Wouters wrote: > On Mon, 5 Mar 2018, Willem Toorop wrote: > >> No Paul, the division in sections is irrelevant for a verifier. The >> only bit of information in a DNS message that is used by a verifier is >> the question. From the question, validation starts and the relevant >> records are followed and verified. But the question section is also not >> needed as the question can be derived from the name and port of the >> service, i.e. ._tcp.. TLSA >> >> The order described in the draft is both an optimization to reduce the >> number of times a verifier has to go over the RRs, and it makes the >> content easier to read (and understand) for humans too. >> >> Also, for non existence answers, DNSSEC validators (and thus also a >> verifier for the chain extension) simply ignore the DNS message header. >> Proof of non-existence can and must be derived from the set of RRs in >> the message body/sections too. > > > Willem (and Shumon and Viktor) have convinced me the DNS Header and > Sections are not needed. > >> The extension already supports Denial of Existence proof b.t.w., because >> it is also needed for wildcard expansions (which are supported). > > > The issue here is the requirement of the TLS server to send these > records in the absence of any TLS record. This allows the clients to > detect a rogue webserver cert that is valid in webPKI but not valid > based on DANE. Without this commitment, the TLS extension does not > really work, as it can be omitted by an attacker. > > Paul > -- Best regards, Kathleen ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
On 3/7/18 12:58 PM, Eric Rescorla wrote: > > - TLS SignatureScheme Registry: Values with the first byte in the > > range 0-253 (decimal) are assigned via Specification Required > > [RFC8126]. Values with the first byte 254 or 255 (decimal) are > > reserved for Private Use [RFC8126]. Values with the first byte in > > the range 0-6 or with the second byte in the range 0-3 that are > > not currently allocated are reserved for backwards compatibility. > > Unless I misunderstand the compatibility mechanisms here, the reservation of > first byte=0-6 seems to assume that no further assignments will be made from > the "TLS HashAlgorithm Registry" (after 4492bis lands). If this is the case, I > would expect the IANA considerations section to include a request that the IANA > close the table to further registrations. The same comment applies to TLS > SignatureAlgorithm Registry. Agreed, but I'd like to hear from the chairs. I think we're still waiting to hear from the chairs on this topic. /a ___ 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 Mon, Mar 12, 2018 at 02:29:55PM -0400, Paul Wouters wrote: > On Mon, 5 Mar 2018, Willem Toorop wrote: > > > No Paul, the division in sections is irrelevant for a verifier. The > > only bit of information in a DNS message that is used by a verifier is > > the question. From the question, validation starts and the relevant > > records are followed and verified. But the question section is also not > > needed as the question can be derived from the name and port of the > > service, i.e. ._tcp.. TLSA > > > > The order described in the draft is both an optimization to reduce the > > number of times a verifier has to go over the RRs, and it makes the > > content easier to read (and understand) for humans too. > > > > Also, for non existence answers, DNSSEC validators (and thus also a > > verifier for the chain extension) simply ignore the DNS message header. > > Proof of non-existence can and must be derived from the set of RRs in > > the message body/sections too. > > Willem (and Shumon and Viktor) have convinced me the DNS Header and > Sections are not needed. > > > The extension already supports Denial of Existence proof b.t.w., because > > it is also needed for wildcard expansions (which are supported). > > The issue here is the requirement of the TLS server to send these > records in the absence of any TLS record. This allows the clients to > detect a rogue webserver cert that is valid in webPKI but not valid > based on DANE. Without this commitment, the TLS extension does not > really work, as it can be omitted by an attacker. One idea for adding pinning: - Add pinned flag to the client request structure. This is set if the client has the server pinned, otherwise clear. - Add max_age field to the server response structure. - If max_age=0, the payload can either be authenticated TLSA RRset or proof no such thing exists. Any sent RRset applies to current connection. In either case, the pin breaks immediately. - If max_age>0, the payload must be TLSA RRset. The TLSA RRset appiles to this connection. Pin the name as requiring this extension for next max_age seconds. - Add security consideration that sending TLSA RRsets with max_age=0 is vulernable to downgrade attacks. The reason for the flag in client request is to tell the server if it should bother sending ADoE back or not. Also, could cached_info extension be extended to cover data for this extension? It would save some bandwidth... -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
> On Mar 12, 2018, at 19:58, Adam Roach wrote: > > On 3/7/18 12:58 PM, Eric Rescorla wrote: >> > > - TLS SignatureScheme Registry: Values with the first byte in the >> > > range 0-253 (decimal) are assigned via Specification Required >> > > [RFC8126]. Values with the first byte 254 or 255 (decimal) are >> > > reserved for Private Use [RFC8126]. Values with the first byte in >> > > the range 0-6 or with the second byte in the range 0-3 that are >> > > not currently allocated are reserved for backwards compatibility. >> > >> > Unless I misunderstand the compatibility mechanisms here, the reservation >> > of >> > first byte=0-6 seems to assume that no further assignments will be made >> > from >> > the "TLS HashAlgorithm Registry" (after 4492bis lands). If this is the >> > case, I >> > would expect the IANA considerations section to include a request that the >> > IANA >> > close the table to further registrations. The same comment applies to TLS >> > SignatureAlgorithm Registry. >> >> Agreed, but I'd like to hear from the chairs. > > > I think we're still waiting to hear from the chairs on this topic. > > /a I think this got lost somewhere in the flurry of emails: See s17 of https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ We don’t close the registry because technically, if somebody really, really wanted to they could register values for earlier versions. spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
On 3/12/18 5:33 PM, Sean Turner wrote: On Mar 12, 2018, at 19:58, Adam Roach wrote: On 3/7/18 12:58 PM, Eric Rescorla wrote: - TLS SignatureScheme Registry: Values with the first byte in the range 0-253 (decimal) are assigned via Specification Required [RFC8126]. Values with the first byte 254 or 255 (decimal) are reserved for Private Use [RFC8126]. Values with the first byte in the range 0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backwards compatibility. Unless I misunderstand the compatibility mechanisms here, the reservation of first byte=0-6 seems to assume that no further assignments will be made from the "TLS HashAlgorithm Registry" (after 4492bis lands). If this is the case, I would expect the IANA considerations section to include a request that the IANA close the table to further registrations. The same comment applies to TLS SignatureAlgorithm Registry. Agreed, but I'd like to hear from the chairs. I think we're still waiting to hear from the chairs on this topic. /a I think this got lost somewhere in the flurry of emails: See s17 of https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ We don’t close the registry because technically, if somebody really, really wanted to they could register values for earlier versions. Ah, thanks for the pointer. I don't agree with your evaluation that draft-ietf-tls-iana-registry-updates preserves the ability to register values for earlier versions, as it marks all remaining available codepoints "reserved." That's effectively equivalent to what I'm asking for, though, so my comment is addressed. There's still a potential mess brewing for the HashAlgorithm codepoints 224 though 253 colliding with SignatureScheme values of 0xE000 - 0xFDFF, but it seems pretty unlikely that SignatureScheme allocations will reach that point before 1.2 and previous versions disappear. /a ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
> On Mar 12, 2018, at 22:46, Adam Roach wrote: > > On 3/12/18 5:33 PM, Sean Turner wrote: >> >>> On Mar 12, 2018, at 19:58, Adam Roach wrote: >>> >>> On 3/7/18 12:58 PM, Eric Rescorla wrote: >> - TLS SignatureScheme Registry: Values with the first byte in the >> range 0-253 (decimal) are assigned via Specification Required >> [RFC8126]. Values with the first byte 254 or 255 (decimal) are >> reserved for Private Use [RFC8126]. Values with the first byte in >> the range 0-6 or with the second byte in the range 0-3 that are >> not currently allocated are reserved for backwards compatibility. > Unless I misunderstand the compatibility mechanisms here, the reservation > of > first byte=0-6 seems to assume that no further assignments will be made > from > the "TLS HashAlgorithm Registry" (after 4492bis lands). If this is the > case, I > would expect the IANA considerations section to include a request that > the IANA > close the table to further registrations. The same comment applies to TLS > SignatureAlgorithm Registry. Agreed, but I'd like to hear from the chairs. >>> >>> I think we're still waiting to hear from the chairs on this topic. >>> >>> /a >> I think this got lost somewhere in the flurry of emails: >> >> See s17 of >> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >> We don’t close the registry because technically, if somebody really, really >> wanted to they could register values for earlier versions. > > Ah, thanks for the pointer. I don't agree with your evaluation that > draft-ietf-tls-iana-registry-updates preserves the ability to register values > for earlier versions, as it marks all remaining available codepoints > "reserved." That's effectively equivalent to what I'm asking for, though, so > my comment is addressed. Subtly different but I’m glad you’re good with this ;) > There's still a potential mess brewing for the HashAlgorithm codepoints 224 > though 253 colliding with SignatureScheme values of 0xE000 - 0xFDFF, but it > seems pretty unlikely that SignatureScheme allocations will reach that point > before 1.2 and previous versions disappear. i may have been lazy when I just did 9-223. We could obviously remove this by marking 224-253 reserved for both the HashAlgorithm and SignatureAlgorithm registries. Note that there are also other unassigned values in 4-6 in SignatureAlgorithms and 7 in HashAlgorithm that should/could also be marked reserved. But, we can do that on the IANA draft in early April. spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
