Re: [TLS] draft-shore-tks-dnssec-chains-extension
On Wed, Jul 22, 2015 at 1:16 PM, Viktor Dukhovni
wrote:
> On Wed, Jul 22, 2015 at 07:45:17AM -0400, Paul Wouters wrote:
>
> > I think the server should stick to one chain, from the root to itself,
> > so it does not have to deal with variable chain blobs per client.
> > That will allow server code to stick to something like hourly
> > regenerating the blob for use with all clients.
>
> >From the root to its own TLSA RRset, however, this can be complicated
> in the presence of CNAMEs:
>
> www.example.com. IN CNAME cdn.example.net.
> cdn.example.net. IN A 192.0.2.1
> _443._tcp.cdn.example.net. IN CNAME _dane.example.net.
> _dane.example.net. IN TLSA 2 0 1
>
> In this example, three leaf RRsets need to be verified back to the
> root (with notable overlaps in the chains):
>
> www.example.com. IN CNAME
> _443._tcp.cdn.example.net. IN CNAME
> _dane.example.net. IN TLSA
>
> How should these be organized? It seems to me that the immediate
> answer that gets the client going in the right direction is the
> first CNAME, which enables to construct the TLSA base domain,
> and then to follow the second CNAME to the ultimate TLSA RRset.
>
There are a number of possibilities here, including more complicated data
structures. But I think we can use the current linear chain structure and
have it composed of multiple sequences corresponding to intersecting
branches of the DNS tree.
For the following hypothetical example:
_443._tcp.www.example.com. IN CNAMEca.example.net.
ca.example.net. IN TLSA 2 0 1
the getdns library's validation chain function currently returns (RRSIGs
omitted for brevity):
_443._tcp.www.example.com. CNAME
ca.example.net. TLSA
example.com. DNSKEY
example.com. DS
com. DNSKEY
com. DS
. DNSKEY
example.net. DNSKEY
example.net. DS
net. DNSKEY
net. DS
Should everything other than the first CNAME be in additional
> records? Should all the above (with their RRSIGs) be in the answer
> section, with the union of the supporting DNSKEY/RRSIG/DS records
> as additional?
>
> I tried to ask a related question during the meeting, but bandwidth
> to explain the context was limited: Should proofs of non-delegation
> be included, to keep gTLDs and ccTLDs honest for some future CT for
> DNS? Specifically, suppose you see:
>
> _443._tcp.www.example.com. IN TLSA
>
> with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3
> records that demonstrate that "example.com" (and www.example.com)
> are not delegated? (Such records might then be subject to "gossip"
> or related "transparency" counter-measures).
>
I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit more
before considering DNSSEC key transparency issues.
It looks like that draft proposes SCT RRs (with DS+chain data in them,
signed by log providers), so we could in the future incorporate SCT RRs in
the chain. However do we really need to? The TLS server is the one doing
the DNS queries, so it could perform the SCT checks against the logs it
trusts, while querying the chain records, and then build the validated
chain. I'm not sure there is a need for the TLS client to additionally do
these log checks, so it doesn't need to have that info delivered in the
chain.
> > As for ekr's question on why not stuff this inside X.509, that would not
> > be compatible with tls raw pulic keys that only contain a SBKI, and drag
> > back into the protocol more ASN.1 parsing and containers.
>
> This really can't go in the certificate, because then certificates
> would have to be updated as often as RRSIGS are regenerated. That
> seems exceedingly unlikely to be deployable.
>
I believe Eric's question was about why this couldn't be done via a new
'Certificate Type' (and not about embedding the chain in the X.509 cert). I
presume the idea being the new certificate type would allow both the
server's X.509 certificate chain and the corresponding DANE/DNSSEC chain to
be delivered in the server's Certificate Message. I believe the argument
for doing it via a new TLS extension was that it would allow us to mandate
the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature
Extension.
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-shore-tks-dnssec-chains-extension
On Tue, Jul 28, 2015 at 10:05 PM, Viktor Dukhovni
wrote:
> On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:
>
> This is no longer the DNS response to a single query (iterative
> resolvers generally chase CNAMEs), since one first CNAME expands
> the original target hostname to obtain the TLSA base domain (provided
> the CNAME chain is validated end-to-end) and then CNAME expands
> the _443._tcp. prefixed base domain to find the TLSA RRset.
>
Hmm, I guess the DANE ops draft says to look for TLSA records at the alias
target rather than the owner name. This doesn't seem to be how many early
HTTPS sites are deploying TLSA records though, e.g. www.ietf.org.
> the getdns library's validation chain function currently returns (RRSIGs
> > omitted for brevity):
> >
> > _443._tcp.www.example.com. CNAME
> > ca.example.net. TLSA
> >
> > example.com. DNSKEY
> > example.com. DS
> > com. DNSKEY
> > com. DS
> > . DNSKEY
> > example.net. DNSKEY
> > example.net. DS
> > net. DNSKEY
> > net. DS
>
> The getdns library is unlikely to handle the fully general case,
> because first the TLSA base domain has to be found.
>
It probably doesn't today. I'll check into this.
> > It looks like that draft proposes SCT RRs (with DS+chain data in them,
> > signed by log providers), so we could in the future incorporate SCT RRs
> in
> > the chain. However do we really need to? The TLS server is the one doing
> > the DNS queries, so it could perform the SCT checks against the logs it
> > trusts, while querying the chain records, and then build the validated
> > chain. I'm not sure there is a need for the TLS client to additionally do
> > these log checks, so it doesn't need to have that info delivered in the
> > chain.
>
> The TLS server is not trusted, the whole point is detect malfeasance,
> where the DNS operator and TLS server conspire to lie (to selected
> clients).
>
Yeah, I had a feeling you'd say this :-) Fair enough, that's an additional
threat we should take into account.
> > > This really can't go in the certificate, because then certificates
> > > would have to be updated as often as RRSIGS are regenerated. That
> > > seems exceedingly unlikely to be deployable.
> > >
> >
> > I believe Eric's question was about why this couldn't be done via a new
> > 'Certificate Type' (and not about embedding the chain in the X.509
> cert). I
> > presume the idea being the new certificate type would allow both the
> > server's X.509 certificate chain and the corresponding DANE/DNSSEC chain
> to
> > be delivered in the server's Certificate Message. I believe the argument
> > for doing it via a new TLS extension was that it would allow us to
> mandate
> > the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature
> > Extension.
>
> I see. I think the question of whether "must staple DANE" is
> supported or not is quite orthogonal to the question of how DANE
> stapled data is encoded.
>
Encoded yes, but not necessarily on what protocol element carries the
encoding. It depends on what mechanism is being used for the must-staple
assertion. The X.509 TLS feature extension mechanism requires a list of TLS
extension values to be specified. Using a new TLS certificate type would
not be compatible with that.
The disadvantage of this being a new certificate type is that AFAIK
> it would then not be orthogonal to the choice between X.509 chains
> and raw public keys. We might then have a (small) combinatorial mess:
>
> traditional X.509 chain
> X.509 chain with stapled DANE evidence
> raw public key
> raw public key with stapled DANE evidence
>
> I think the extension is a more logical separation of duties, but
> I am willing to hear contrary arguments.
>
Yes, I agree.
Shumon Huque.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] dnssec_chain entry in IANA registry seems to be missing CT
On Wed, Feb 16, 2022 at 4:29 AM Ilari Liusvaara wrote: > I noticed that the "dnssec_chain" extension in the IANA registry lists > only "CH" in the "TLS 1.3" column. However, the extension sends its > response in the certificate message (section 2.2), so I think that > column should read "CH, CT". > You are right, Ilari. What's the process to get the IANA registry corrected? Shumon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] dnssec_chain entry in IANA registry seems to be missing CT
On Tue, Feb 22, 2022 at 8:39 PM Benjamin Kaduk wrote: > On Tue, Feb 22, 2022 at 08:27:02PM -0500, Shumon Huque wrote: > > On Wed, Feb 16, 2022 at 4:29 AM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > I noticed that the "dnssec_chain" extension in the IANA registry lists > > > only "CH" in the "TLS 1.3" column. However, the extension sends its > > > response in the certificate message (section 2.2), so I think that > > > column should read "CH, CT". > > > > > > > You are right, Ilari. > > > > What's the process to get the IANA registry corrected? > > It is probably "best" (for some definition of "best") to publish an RFC > that Updates: 9102 and has the revised directive to IANA. > Ouch! > Probably an errata report should be filed against RFC 9102 regardless. > IANA might be able to use the errata report without the updating RFC, > but you'd have to ask. > Let's see if this path works first. Shumon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
On Tue, Feb 6, 2018 at 10:39 PM, Adam Roach wrote: > On 2/6/18 9:28 PM, Viktor Dukhovni wrote: > >> >> On Feb 6, 2018, at 10:19 PM, Adam Roach wrote: >>> >>> Unless I missed something important, this scenario doesn't seem to make >>> much >>> sense: if the client provides name A and the server replies with name B, >>> the >>> client either (1) isn't performing server name validation (in which case >>> it is >>> nonsense for the client to ask for a dnssec_chain), or (2) is going to >>> error >>> out the connection. Do I have that right? If there's some situation in >>> which >>> the server acting as described above provides some benefit, I would love >>> to >>> see it described in here. If it's just a matter of having completely >>> described >>> behavior for corner cases, it may be worthwhile indicating that the >>> client >>> will reject the connection if the server decides to complete the >>> handshake >>> like this. >>> >> DANE clients sometimes accept more than one name for the server. This >> happens >> when the server name is obtained indirectly from MX OR SRV records, or as >> the >> result of (DNSSEC-validated) CNAME expansion. >> > > Ah, that's an interesting point. You may want to keep this in mind when > responding to the question put forth by the GEN-ART reviewer. > > So in principle, more than one name might be acceptable to the client. In >> practice however, I don't yet see a mechanism where a client that can't do >> DNSSEC validation on its own would be in a position to do this. >> > > My understanding is that this mechanism isn't just for clients that can't > do their own DNSSEC validation; it's also intended to reduce latency for > interactive applications (web browsers and real-time-communication clients > in particular). > >> >> > Yes, that's true. But if we were to consider the MX/SRV use case, then for this specification to be complete, it would have to consider clients that are unable to validate on their own. This means the dnssec_chain extension would have to provide records that can (also) validate the MX or SRV records, which it doesn't do right now. In early discussions about the scope of this draft, I believe we decided to omit the MX/SRV case to keep things simple. This is why the draft only references RFC 6698 and 7671, and not 7672 and 7673. (Well it mentions 7672 only tangentially to suggest that such clients likely won't need this mechanism). Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
On Tue, Feb 6, 2018 at 10:19 PM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-tls-dnssec-chain-extension-06: 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: > -- > > I like this mechanism and look forward to its deployment. I have one point > of > clarification and a small handful of editorial comments. > > First, the point of clarification: > > §4: > > > if the server does not recognize the > > provided name and wishes to proceed with the handshake rather than to > > abort the connection, the server uses the domain name associated with > > the server IP address to which the connection has been established. > > Unless I missed something important, this scenario doesn't seem to make > much > sense: if the client provides name A and the server replies with name B, > the > client either (1) isn't performing server name validation (in which case > it is > nonsense for the client to ask for a dnssec_chain), or (2) is going to > error > out the connection. Do I have that right? If there's some situation in > which > the server acting as described above provides some benefit, I would love to > see it described in here. If it's just a matter of having completely > described > behavior for corner cases, it may be worthwhile indicating that the client > will reject the connection if the server decides to complete the handshake > like this. > > > --- > > > Intended status: Standards Track R. Barnes > > Expires: July 27, 2018 Mozilla > > s/Mozilla/Cisco/ > > > --- > > §1: > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119]. > > This document has significant usage of these terms in lowercase. Please > consider > using the boilerplate from RFC 8174 instead. > > > --- > > §3.3: > > > the case in DANE in which a client either ignores the name in > > certificate (as specified in [RFC7671] or there is no attestation of > > Nit: "...in the certificate..." > > Nit: Add closing paren after [RFC7671] > > > --- > > §4: > > > specific processing needed for aliases and wildcards. If DNS > > responses messages contain any domain names utilizing name > > Nit: "response" > > Adam - nits have been noted, and will be fixed. Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Genart telechat review of draft-ietf-tls-dnssec-chain-extension-06
On Tue, Feb 6, 2018 at 8:25 PM, Matthew Miller < linuxwolf+i...@outer-planes.net> wrote: > Reviewer: Matthew Miller > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-tls-dnssec-chain-extension-06 > Reviewer: Matthew A. Miller > Review Date: 2018-02-06 > IETF LC End Date: 2018-02-07 > IESG Telechat date: 2018-02-08 > > Summary: > > This document is ready, with one issue that I think could benefit > from some clarification. > > Major issues: > > NONE > > Minor issue: > > This is more a question, that might warrant some clarification: > In 7. Verification, the last paragraph discusses client-side > caching of the RRsets. If a client has cached the full RRset chain > from TLSA to root RRSIG (and that cache is still viable), is the > client still expected to specify the "dnssec_chain" extension? > > In my reading, that does not seem necessary, and I think it might > be worth noting if that is true. > Yes, if the client has cached either the validated TLSA RRset or the full chain, then it doesn't need to send the dnssec_chain for subsequent connections. If it has only cached other portions of the chain, then it needs to. We can clarify this. Shumon Huque ___ 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 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. >unsigned CNAME records that may have been synthesized in the response >from a DNS resolver. > > 2) TLS 1.3 needs to be a normative reference, but it is not even listed in > References. > Ok, we will add it. > -- > COMMENT: > -- > > The first mention of NSEC3 need a normative reference. > Yup, will do [RFC 5155] Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
On Wed, Feb 7, 2018 at 6:22 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-tls-dnssec-chain-extension-06: Yes > > -- > COMMENT: > -- > > I am happy to see this published, but have a few minor comments: > > - I agree with Alexey's comments. > Yup, addressed previously in email .. > > -3.4: "If the TLSA record set was synthesized by a DNS wildcard, the chain >must include the signed NSEC or NSEC3 records that prove that there >was no explicit match of the TLSA record name and no closer wildcard >match." > > Should that "must" be a "MUST"? > Yes, thanks for catching that. > > - Nit in Authors List: Unless I've missed something, Richard's affiliation > is > no longer current. (I only point it out in case it's an oversight; I have > no > objection if it's that way on purpose.) > I'll let Richard chime in .. 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 7, 2018 at 8:21 AM, Mirja Kühlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-tls-dnssec-chain-extension-06: No Objection > > -- > COMMENT: > -- > > Two minor, mostly editorial comments: > > 1) Intro (sec 2): " It also provides the >ability to avoid potential problems with TLS clients being unable to >look up DANE records because of an interfering or broken middlebox on >the path between the client and a DNS server." > Is that actually a well-known problem (can you provide a reference?) Some folks (at Google and NLnet Labs if I recall; maybe others) have done measurements to show this is an actual problem -- for a relatively small but still non-trivial fraction of clients. We'll try to see if we can dig up specific references to documents that could be cited. or would > it be enough to say something like this: " It also provides the >ability to avoid potential problems with TLS clients being unable to >look up DANE records when DNS server is not reachable." > Your rewording of this sentence would unfortunately not be accurate. It's usually not the DNS server that is unreachable, but that some middlebox has done something wrong, such as: not allow DANE queries or responses through; not allow DNSSEC signatures through; not allow EDNS options that enable DNSSEC through, or engage in other misbehavior. > 2) IANA Considerations should probably be updated. > I guess you are suggesting that the last sentence is probably obsolete: "If the draft is adopted by the WG, the authors expect to make an early allocation request as specified in [RFC7120]." Agreed. It's a little late for that! :-) We will remove it. Shumon Huque ___ 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)
there are > other UKS attacks Ok, we will clarify this. > I think you probably want to cite SIGMA and triple handhshake here. Ok. > > opaque AuthenticationChain<0..2^16-1> > Is 0 actually appropriate here as a lower bound? Presumably at least one such > instance must be present? Yes, there should be a non-zero number of bytes in the extension data. So: opaque AuthenticationChain<1..2^16-1> > > RR(i) = owner | type | class | TTL | RDATA length | RDATA > I assume the notation here is "i is the ith RR"? Yes, we can mention that. > > Is there a reason not to describe this in TLS language? I think because the extension data contains only a sequence of DNS wire format RRs which are precisely defined in DNS documents, and we felt it was redundant to redefine them in another format. > > . DNSKEY > RRSIG(. DNSKEY) > How does this differ from the algorithm that you would use in response to the > TLSA query? Sorry, I don't follow your comment here. Differ from what? Can you elaborate? > >the draft is adopted by the WG, the authors expect to make an early >allocation request as specified in [RFC7120]. > Do you want this to be marked RECOMMENDED? In response to Mirja's earlier comment, I think we are taking out this sentence. Shumon Huque ___ 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 Thu, Feb 8, 2018 at 4:51 AM, Willem Toorop wrote: > Op 08-02-18 om 03:27 schreef Shumon Huque: > > On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind > <mailto:i...@kuehlewind.net>> wrote: > > > > Mirja Kühlewind has entered the following ballot position for > > draft-ietf-tls-dnssec-chain-extension-06: No Objection > > > > > -- > > COMMENT: > > > -- > > > > Two minor, mostly editorial comments: > > > > 1) Intro (sec 2): " It also provides the > >ability to avoid potential problems with TLS clients being unable > to > >look up DANE records because of an interfering or broken > middlebox on > >the path between the client and a DNS server." > > Is that actually a well-known problem (can you provide a reference?) > > > > > > Some folks (at Google and NLnet Labs if I recall; maybe others) have done > > measurements to show this is an actual problem -- for a relatively small > but > > still non-trivial fraction of clients. We'll try to see if we can dig up > > specific > > references to documents that could be cited. > > I wouldn't call it a relatively small fraction :) DNSSEC is severely > hampered for end-entities by broken infrastructure in many different > ways. Sometimes an upstream resolver can be used for positive DNSSEC > answers (i.e. existing records), but not for non-existent or wildcard > answers, because it simply doesn't forward the NSEC(3) proof for it. > > The last measurements we at NLnet Labs did was in July 2015: > > Gorjón, Xavier Torrent, and Willem Toorop. > "Discovery method for a DNSSEC validating stub resolver." > (2015) > > https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf > > Measurements were done with RIPE Atlas, with at the time +-8200 probes. > At the time only 56% of probes received enough DNSSEC data from their > upstreams to be able to perform DNSSEC validation for both positive and > non-existent answers (required for DANE). > Ah, thanks. I'd forgotten that it was so high! I think my "relatively small" comment was recalling an earlier study (I think by Google) that saw a breakage of around ~ 5%, but I think that was just measuring the ability to lookup and obtain less common RR types and did not measure ability to perform full DNSSEC validation. 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)
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. &g
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] 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 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 2:48 PM, Paul Wouters wrote: > 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. > It would _not_ be correct to say that this is a "DNS wire format message" - that would mean there is a DNS header section with flags and response codes, and other sections. The chain data structure as currently specified really is concatenated wire-format RRs (as they appear _within_ a DNS message _section_). Let me know if that is unclear in the draft (or my proposed edits). I recall at one point way back there was a discussion about whether the chain data should just be a fully formed DNS message, but I don't believe that idea had much support in the working group (personally I would have been fine with that choice too, if it did have support). > 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. > Yes, that is in fact where we ended up, roughly. The draft does currently say that the answer record(s) appear first. And then the authentication chain records follow and that TLS client should be prepared to receive the authentication chain records in any order. Requiring the answer records first seems logical to me - it is what existing libraries do, and also what the EDNS chain query spec does (answer records appear first in the ANSWER section, and DNSSEC authentication chain records appear in the AUTHORITY section in any order). There is some residual wording in the draft about ordering of CNAMEs etc in the answer records part. Assuming the WG agrees, I am fine with relaxing that requirement - that ended up in there because although there is no defined ordering of RRs within a DNS message section, as a practical matter CNAMEs are almost always ordered since there are some DNS queriers that get confused otherwise. This is a new protocol though, so we can be more faithful to the DNS spec. 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). > The draft currently doesn't address the MX or SRV use case. I suggest that we tackle that in a future version. 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". Where we ended up, is that WG participants asked for some level of DNSSEC detail to be included in this doc. 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 1:49 PM, Viktor Dukhovni wrote: > > > > On Feb 21, 2018, at 11:00 AM, Shumon Huque wrote: > > > > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson < > martin.thom...@gmail.com> 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. I meant same in the sense that if any extension is blocked then it can't be used. What the effect of that is depends obviously on what functionality the extension is providing. The TLS client can at least detect such blocking/stripping, and alert the application or fallback to something else. Have other TLS extension specs gone into the details of middlebox impacts? > 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. > Some of this is already discussed or at least implicit in the draft. If you want to propose specific text to add or modify, please do so .. 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 12:51 PM, Eric Rescorla wrote: > > > On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque wrote: > >> >> 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 servers that support both DANE and traditional PKIX. >> > > That would be my proposal, but I think at least you need to provide the > kind of analysis you do here. > Okay, I'll include that analysis and recommendation. >> > >Servers receiving a "dnssec_chain" extension in the ClientHello, >> and >> > > >which are capable of being authenticated via DANE, SHOULD return >> a >> > > >serialized authentication chain in the extension block of the >> > > > Why is this a SHOULD where the corresponding reqt for TLS 1.2 and >> below >> > > is a >> > > > MAY? >> > > >> > > They should clearly be consistent. My preference would be "SHOULD" for >> > > both. >> > > >> > >> > That's a WG decision. >> >> Ok. Let me know how you want to handle this question. I'd be happy to >> send a separate note to the WG list about it. >> > > Sorry, I didn't mean to discount your view. I meant that I didn't think it > was > role to say which one it should be. > > This is actually a question for the chairs and the AD (Kathleen). If they > think the > WG decided this, then you can just do "SHOULD". If they think it requires > WG > consultation, then you should do that > Ok. > > > >the draft is adopted by the WG, the authors expect to make an >> early >> > > >allocation request as specified in [RFC7120]. >> > > > Do you want this to be marked RECOMMENDED? >> > > >> > > In response to Mirja's earlier comment, I think we are taking out this >> > > sentence. >> > > >> > >> > You're still registering the code point, so you need to determine if >> it's >> > RECOMMENDED or not. >> >> Sorry for being dense - this protocol requires a new codepoint. Do we >> need to say we RECOMMEND that a new code point be registered? >> >> Or are you asking that we RECOMMEND that IANA allocates our preferred >> extension type value (53)? >> > > No. There is a column in the code point assignment for IANA that says > whether the IETF recommends the use of this extension or whether we're > just assigning the code point but don't recommend it. So you need to say > which one it is. I assume the WG wants "Recommended" > Ah, got it. Since the WG adopted this document, "Recommended" would be my assumption too. I'll start making edits based on issues/comments raised in this thread in the github repo, if folks want to follow along, and/or participate: https://github.com/tlswg/dnssec-chain-extension I'll circle back on list when it's ready for review .. 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 Thu, Feb 22, 2018 at 11:08 AM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > On Thu, Feb 22, 2018 at 10:59 AM, Shumon Huque wrote: > > On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni > > > > > Have other TLS extension specs gone into the details of middlebox > > impacts? > > This one is a little different though as end users are expecting e2e > without interference with this extension. Understanding the behavior > is important for administrators and users as Viktor stated. > > Best regards, > Kathleen > Okay Kathleen. We'll add some discussion on this. Viktor - I assume you'll help with text. 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 Thu, Feb 22, 2018 at 12:21 PM, Viktor Dukhovni wrote: > > > My comments are less about middleboxes (TLS-terminating corporate > proxies trusted by the user's browser) and more about unwanted > active MiTM attacks. If the MiTM attacker has obtained WebPKI > (PKIX) certificates for the destination, then this new extension > will not protect the user even when the destination has TLSA > records, because the server can deny their existence (not offer > the extension) without proof. > > What makes this case different is that the naïve mental model > of what it offers is support for DANE-based peer authentication > equivalent to doing the DNSSEC lookups on the client end, but > with DNSSEC tunneled via the server. > > Therefore, some text is probably warranted to disabuse the reader > of such a naïve view. What one gets with this extension, in the > more typical cases in which DANE is not "mandatory", is not > equivalent to enforcing DANE when it is published by the peer. > Rather, what one gets is the ability to use DANE to authenticate > sites that one might not otherwise be able to authenticate (no > shared WebPKI trust-anchor). > Yes, I agree that some elaboration on this limitation of the protocol is useful. In case you missed it, I do actually document the limitation quite explicitly in Section 8, which I'll excerpt here: "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." But perhaps it needs to feature more prominently in the document rather than being buried in the context of a discussion about mandating the use of this extension. The limitation exists independent of whether a TLS application is trying to mandate things. My suggestion is to move this discussion to the beginning of the Security Considerations section, and then adding some of your elaborating points, including a direct comparison with clients querying DANE records themselves. It might also be worth a brief mention in the Intro section that the protocol lacks authenticated denial and pointing the reader/implementer to the Security Considerations section for more details. Shumon Huque ___ 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, Feb 26, 2018 at 12:19 PM, Viktor Dukhovni wrote: > > I think that as it stands, lack of authenticated denial of existence is > a *fatal* flaw in the protocol. I just don't see a sufficiently practical > scenario in which this extension confers a useful security benefit. Viktor, Is this a new realization you've recently arrived at? You've been commenting on this draft for a number of years now, and I have assumed that you were well aware of the lack of authenticated denial. In fact, there is text in the Intro section that declares that this protocol is unsuitable for SMTP/DANE precisely because it requires confirmation of the existence or not of the TLSA record - that text came about because of discussion with you. Several of us were well aware of this during the early days of the draft, but perhaps many folks did not fully appreciate the impacts until I elaborated on them last year, and added text that described the "adversary with fraudulently obtained PKIX credentials" attack. It is certainly a limitation/flaw. Whether or not it is fatal is debatable. What this means is that this protocol allows opportunistic use of DANE authentication, but guarantee of use needs mechanisms external to the protocol. Section 8 already describes several such mechanisms that could be employed. So, I think this topic is covered. This limitation also may not be applicable at all for green field TLS/DNSSEC applications that can require the use of the extension unconditionally. Having an authenticated denial mechanism would allow the TLS client to have an inband way to enforce DANE authentication if available. I suspect though that re-introducing a debate on this topic will lead us into an argument about what it means for a server to publish a TLSA record. Is it just a mechanism to use the DNSSEC to authenticate keys and certificates? Or is it also a policy signal that says DANE must be used? I do not think the latter idea has any consensus in the IETF currently. > Perhaps this draft should go back to the working group, to consider a new > protocol element, by which the server commits to support the extension for > a time that is substantially longer than the underlying DNS TTLs. During > this time (suggested to be weeks or months, when in production after initial > testing), the server MUST support the extension and respond with EITHER a > valid TLSA RRset chain, or with a valid denial of existence. This is a rather substantial change proposal. It's worth considering, but I'd like to hear others chime in. But as I said, there are ways to use this spec and address some of the limitations outside the protocol today - you can cache and pin knowledge of TLSA existence, even without an in-protocol commitment, although the latter would be better. That may be good enough for the first iteration of the protocol. Note that extending the protocol to incorporate authenticated denial also means that the chain data would likey need a DNS response code. That's a stronger argument to move to a full DNS message format (I'll answer Paul Wouter's specific comments on that topic separately later). 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 Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > > Several of us were well aware of this during the early days of the > draft, but perhaps many folks did not fully appreciate the impacts > until I elaborated on them last year, and added text that described > the "adversary with fraudulently obtained PKIX credentials" attack. > Following up to my own message, sorry .. It occurred to me that perhaps a good way to mitigate this risk is a combo of mechanisms like CAA and Certificate Transparency logs. Shumon Huque ___ 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 28, 2018 at 3:07 PM, Nico Williams wrote: > IF there's an objection to modifying the extension in order to add a > pin-to-DANE TTL field, I would propose the following instead: > > Make the pin-to-DANE be "forever" but make it so it can easily be > cleared if DANE is undeployed for the service. > This option is already covered in the draft. It doesn't use the term pinning, but does mention caching the existence of DANE on first contact and requiring it subsequently (if clients want to do so). I do not know if the draft authors and/or WG have an appetite to do the much more major change suggested by Viktor (i.e in-protocol pinning TTL commitment and requiring subsequent denial of existence proof if DANE is removed). 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 Tue, Feb 27, 2018 at 6:36 PM, Nico Williams wrote: > On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote: > > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > > Several of us were well aware of this during the early days of the > > > draft, but perhaps many folks did not fully appreciate the impacts > > > until I elaborated on them last year, and added text that described > > > the "adversary with fraudulently obtained PKIX credentials" attack. > > > > Following up to my own message, sorry .. > > > > It occurred to me that perhaps a good way to mitigate this risk is > > a combo of mechanisms like CAA and Certificate Transparency logs. > > NO. That's insanely complicated. Is it really? We're talking about a scenario of incremental deployment of DANE in an existing PKIX ecosystem. In such an environment, I would expect that many servers will likely support both PKIX-only and DANE, at least initially. So presumably they will already be paying attention to CT logs to detect mis-issuance. And even if they support only DANE, they might be concerned about an attacker impersonating their service to DANE unaware clients. 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)
Hi Kathleen, Sorry for the delay. We'll have an updated draft addressing the IESG discuss/comments shortly after the I-D submission window opens early this week. The one other sticking point is the issue that Viktor has raised about extending the protocol to provide pinning to prevent downgrade to PKIX. That has not been resolved on list yet, so I assume will be discussed at Wednesday's TLS session. Shumon. On Mon, Mar 12, 2018 at 7:22 PM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey wrote: > Hi Folks, > > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the > working group is either to publish the document as is or to bring the > document back into the working group to address the following issues: > > - Recommendation of adding denial of existence proofs in the chain > provided by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document. Please answer > the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? > Yes. I support the publication of the document as is. and would like to explain my position a bit. I'm very sympathetic to Viktor's desire to enhance this protocol to provide downgrade resistance against PKIX attacks, and I generally would share that desire too. But I would also like to publish a document that has the solid consensus of the community that is one of key potential target consumers of this draft (web browsers and servers). So I'm giving more weight to their views and preferences. To date, the only people from that community that have spoken up have expressed strong opposition to Viktor's proposed enhancement. I also feel that the amount of time it has taken to finish up this draft has significantly hurt its deployment chances. In the early days of this draft there was (in my view) a window of opportunity where some browsers had actual interest in implementing this spec. But in the intervening time, there have been enough bandaids (CT and strengthed CAB forum requirements) applied to the WebPKI that to many people in the web community, the risk of bad actors has been sufficiently mitigated. But to the extent that there are still some folks interested in this proposal, I see no benefit in proposing an additional feature that they've stated doesn't work for them, or that they will not use. Another important facet of this debate that so far has not surfaced on recent mailing list discussions is an assessment of the relative benefits of webpki versus dane, and the recognition that there are strongly divergent views on this topic. In the early days of this draft, a number of web folks made it quite clear to me that this protocol can't be used to compel the use of DANE, and that the browser gets to decide what to use (and so dane-to-pkix downgrade attacks were not a concern for them). The large majority of DNSSEC proponents I know (and I'll state upfront that I'm one of them) clearly feel that DANE is superior to webpki, and that it's logical that DANE should be used to address webpki security issues. But this view is not shared by many others, most particularly in the web community. I've been involved in many lengthy debates on this topic, and the arguments against DANE usually boil down to: (1) widespread use 1024-bit RSA as the weak link in the majority of DNSSEC chains, (2) mistrust of registrars and their potential security failings, (3) mistrust of registries and/or other ancestor zones that could mount targeted attacks that could only be detected by a DNSSEC key transparency system, ala CT. These are legitimate arguments, and until we have better answers to them, I'm not inclined to aggressively push DANE, and position it as unconditionally superior, on communities that have expressed these concerns. Viktor has asserted that no-one will be motivated to deploy DANE without protection against PKIX downgrade, because there is no compelling enough additional gain of security. He may be right or wrong, but I've already heard several web folks disagree with him. And furthermore, they've expressed what I think are legitimate concerns about the fragility of the pinning proposal. Yes, I agree that it's not as bad as HPKP, but I also agree that there are more risks and failure possibilities than HSTS. As for other applications, we've already heard from a number of folks in the DNS over TLS camp that the draft works for them in the current form. Most DNS over TLS clients are expected to have explicit configuration of their resolver addresses and DANE capabilities. Some possible ways forward I see for folks wanting to develop a version of this spec with PKIX downgrade resistant capabilities (I've already stated earlier, that I would be happy to participate in such efforts): * Develop a new spec, with a new codepoint, and let the specs compete for adoption. * Develop a -bis document - if we manage to get WG consensus on the approach at a later date. * Do something outside the protocol, and specific to applications that want to include mechanisms to mandate DANE usage (like a HTTP header). -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Tue, Apr 10, 2018 at 12:48 PM, Benjamin Kaduk wrote: [...] > I concede that it remains useful to consider what the client will do > with the received DANE records or denial thereof, so as to not unduly > block off future routes for development. But it seems at least possible > to take > a very broad view in this space, including even the possibility of > additional > TLS extensions that can modify the behavior of this one (such as a > modification > to provide pinning-like behavior). Maybe that's the best option. Advance the current document as-is. And also develop a separate DANE pinning extension (now'ish ..) -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Tue, Apr 10, 2018 at 11:22 AM, Paul Wouters wrote: > On Tue, 10 Apr 2018, Willem Toorop wrote: > > I just want to clarify one misconception in Willem's statement. See my > previous emails to thist list for my full arguments on this issue. > > The chain extension already contains verification of Denial Of Existence >> proofs, because that is needed for verifying wildcard expansions. >> > > This might confuse people. I am talking about denial of existence of any > TLSA record. You are talking about proof of non-existance of other TLSA > records besides the one you are returning. These are completely > different issues. I just want to ensure people realise when I said we > need proof of non-existence, that people do not read your line "already > contains this" as me being wrong. > > > It does not explicitly mention the fallback to non-PKIX with a Denial of >> Existence proof or insecurity proof for the TLSA record, because it is >> (currently) irrelevant when the extension could simply be left out too. >> > > So that's not one bug, but two bugs. Defining them out of scope is not > what we should do. For instance, the document could already assume that > the proof of TLS extension (pinning) is going to be solved elsewhere, > and therefor a full denial of existence proof in this document would be > valuable. > > The document does not specify what to do when it does not find a TLSA > record to include. It does state: > > If the server is configured for DANE >authentication, then it performs the appropriate DNS queries, builds >the authentication chain, and returns it to the client. > > So if the server is configured for DANE, and it only finds denial of > existence proofs of its own TLSA record, what is the expected behaviour? > > This hints at returning the proof of non-existence, but clearly even the > authors are now saying they did not mean this and a server is not > required to do this. Clearly the text needs clarification, and if it > then leaves out denial of existence, it needs a justification for that > as well. Personally, I would be okay with relaxing/clarifying the language in the draft a bit so that it does not rule out the possibility that a DNSSEC (NSEC/NSEC3) chain corresponding to an NXDOMAIN or NODATA response can be returned. I wonder if that, together with a new extension that can convey DANE pinning information is a way forward .. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Thu, Apr 12, 2018 at 6:09 PM, Viktor Dukhovni wrote: > > > > On Apr 12, 2018, at 5:47 PM, Martin Thomson > wrote: > > > > If this is indeed about adding [goo], what prevents Viktor or Paul > > from proposing a new addition to the protocol in the form of a new I-D > > that enacts the changes they wish to see? > > Why publish a crippled specification that needs immediate amendments that > would > require a second parallel extension to be defined and used by clients and > servers > to fix the issues in the current specification? And the time to get that > second > extension would effectively delay the publication of a usable protocol. > > The protocol as described prohibits denial of existence responses. Willem > acknowledged (thus far in an off-list message) that that's an oversight > that > should be corrected, and such a correction is the substance of option (A). > As I said in a previous message, I'll support relaxing the language in the draft to permit delivery of authenticated denial chains for future applications of the protocol - I think that's just adding or modifying a couple of lines to the draft, and no wire changes. Someone actually argued to me in person that the draft could be read as not explicitly prohibiting authenticated denial (for NXDOMAIN/NODATA), but if we want to allow it, I think it's best to be crystal clear. If we can get consensus on that, then you could write a separate extension to convey the pinning information and describe the additional behavior. That in combination with the existing draft would satisfy your use case. That would in fact be an incremental addition, and not a whole new parallel protocol. Implementers that are opposed to pinning would then just ignore this second draft (and not bother with the authenticated denial part of the first draft). Since it seems pretty clear you're not going to consensus on adding pinning to the current draft, I think you should pursue this approach. And then you can try to convince implementers and deployers, now or in the future, that they need to use both extensions in combination. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters wrote:
>
> 2. Explicitly allow (but do not require) DoE be included
>>
>
> The document does not currently allow the extension to be empty. So if
> there is no TLSA record and the extension would be present, it therefore
> can only contain a DoE chain. So what do you mean with item 2? Possibly
> you mean to say "if there is no TLSA record, the extension can be omited
> or the extension can be included with a DoE chain" ? That would be okay
> with us.
Yes, my understanding is that's what it means.
Note that Section 8 ("Mandating Use") already did hint at the future
possibility of
this extension carrying a DoE chain that could be deployed in a TLS
application
ecosystem where all servers understood and were prepared to respond to this
extension. The plan is to now add text that allows DoE chains more
generally,
with details of use defined in subsequent documents.
Shumon.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Draft updates: tls-dnssec-chain
> On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey wrote: > Concerns have been raised about the trade-offs associated with pinning and I do not think we currently have consensus to add pinning. While I think it may be possible to come to consensus on pinning I think it may take some time. I believe we can quickly get consensus for the following approach: > > 1. Scope the document to the assertive use cases > 2. Explicitly allow (but do not require) DoE be included > 3. Remove current text about pinning > 4. Re-submit the document for publication and start work on a separate extension that supports pinning Hi Joe, Here is the proposed text for items 1, 2, and 3. It's also in the tls-wg github repo. We'll probably tweak and wordsmith some more, but this is the gist of it. > 1. Scope the document to the assertive use cases * Added scope description to Intro: This specification can also be used to optionally convey authenticated denial of existence of TLSA records. Restrictive uses that might require such proofs (such as the PKIX constraining modes of DANE, or where DANE should always be preferred over other modes of authentication such as traditional PKIX) are thus not in its intended scope. Such restrictive uses can however be supported opportunistically. > 2. Explicitly allow (but do not require) DoE be included (Note: I've noticed Viktor has submitted some expanded text describing denial of existence. We'll review and likely incorporate much of that) * New section: 3.4.1, that permits but doesn't require authenticated denial: 3.4.1. Support for Authenticated Denial of Existence TLS servers that do not have a signed TLSA record MAY instead return a DNSSEC chain that provides authenticated denial of existence. This specification does not require TLS servers to provide such a denial of existence chain, otherwise it could not be deployed incrementally in environments where not all TLS servers support this extension. Authenticated denial chains include NSEC or NSEC3 records that demonstrate one of the following facts: o The TLSA record does not exist. o There is no signed delegation to a DNS zone which is either an ancestor of, or the same as, the TLSA record name. * Text in Section 8 (Mandating) that rewrites language that in the previous draft stated that it doesn't support denial of existence: This protocol allows TLS servers to prove that they don't have a signed TLSA record by returning a denial of existence chain. However, as explained in Section 3.4.1, it does not require TLS servers to do so. In the absence of such a proof, a TLS 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. Application ecosystems where all TLS servers are expected to implement this extension could require such authenticated denial proofs to be delivered by TLS servers that don't have signed TLSA records. > 3. Remove current text about pinning * Remove client initiated pinning para from Section 8: This paragraph was entirely deleted: If TLS applications want to mandate the use of this extension for 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. 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. Thanks, -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
On Fri, Apr 27, 2018 at 4:17 PM, Viktor Dukhovni wrote: > > It would be helpful to know where opponents stand on negotiating > continued use of the extension in general and in the future. We > are confused by their statements so far, and wonder if they are > not just generally in opposition to any negotiation of continued > support for the extension (in all applications), and whether that > might be driving their opposition to the 16 bits, whether consciously > or not. > Hi Viktor, I am in support of doing the pinning in a new extension, and will even help you write the draft if you like. I'm pretty sure we could have easily done this in the time that has been taken up on list endlessly and repetitively discussing this. Clearly I can speak only for myself, but I strongly suspect others in the WG will also support this (as long as it's in a separate extension), so if you pursue this approach, I think you'll succeed in adding this functionality, and will not be actively blocked by others. As far as I can assess, the reason you are getting resistance for adding a pinning field in this spec is two fold: First, there is no agreement that your reason for doing pinning, i.e. that DANE needs downgrade resistance against PKIX attacks is even valid. This can be clearly seen from various comments on list and at IETF/London, such as the point made many times that the original purpose of this draft was to add DANE as an additional possible authentication mechanism in TLS, not to position it as a mechanism that if available unconditionally trumps PKIX authentication. If you look back at my back-and-forth answering IESG review comments, you will observe that I had to add text to the draft that says TLS clients can fail back to normal PKIX authentication if DANE fails for any reason (i.e. a protocol behavior that is the opposite of downgrade resistance). There are other comments like (paraphrasing) "What's the downgrade problem? The only security downgrade issue I see is DNSSEC's use of legacy crypto"? Clearly, for most DANE proponents, an obvious goal for the protocol would be to protect against PKIX attacks. In an ideal world, I share that view also. But I also recognize the other views I just described, and am willing to make compromises to get a foot in the door for DANE first. There will always be opportunities to improve the protocol later. In fact, the legacy crypto issue will always be a huge impediment for any DANE proponent in arguing against the Internet PKI. An argument I've heard many times: Since most of the Internet PKI has moved to 2048-bit RSA or better, why would I degrade the security of my system by moving to DANE, which in most cases is protected by 1024-bit RSA ZSK's in the weakest part of the chain (some chains are even weaker)? And if so, why should PKIX not need downgrade resistance against DANE, rather than vice versa? For DANE proponents to make a stronger case, they need to urgently solve this problem. I'm not sure how to do that quickly - it probably involves getting ICANN to impose rules on TLDs prohibiting weak keys (which would likely take years). The second reason is that pinning really is a controversial feature. And for this reason, putting it in the core spec will be difficult. I won't repeat all the arguments and concerns expressed already, many of which I share by the way. So moving this feature into a new optional extension (both the pinning field and a description of the associated behavior) appears to me to be the past of least resistance. By continuing to argue your position, the most you can hope to achieve is deadlock. Shumon. (Addendum: I did want to thank you for pushing on the issue of explicitly allowing authenticated denial of existence chains in the current draft. In environments where all TLS servers support this extension, this allows the protocol to be bulletproof in a way that satisfies even the security purist, so I'm glad it's in the core spec.). -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
On Sat, Apr 28, 2018 at 1:40 PM, Viktor Dukhovni wrote: > > > On Apr 28, 2018, at 12:26 PM, Shumon Huque wrote: > > > > So moving this feature into a new optional > > extension (both the pinning field and a description of the associated > > behavior) appears to me to be the past of least resistance. > > I wish I could be confident that such a specification would > be allowed to move forward. My fear is that the same visceral > opposition to DANE and DNSSEC would play out, and so I may as > well try to get past these now. > I would like to explore this. Is there anyone in the working group who would oppose such a new spec moving forward? (Maybe the WG chairs need to ask this question officially). Shumon ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft updates: tls-dnssec-chain
On Sat, Apr 28, 2018 at 2:17 PM, Richard Barnes wrote: > > > On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni > wrote: > >> >> >> > On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote: >> > >> >This specification can also be used to optionally convey >> >authenticated denial of existence of TLSA records. Restrictive uses >> >that might require such proofs (such as the PKIX constraining modes >> >of DANE, or where DANE should always be preferred over other modes of >> >authentication such as traditional PKIX) are thus not in its intended >> >scope. Such restrictive uses can however be supported >> >opportunistically. >> >> The last sentence makes no sense. The term "Restrictive uses" is poorly >> defined. The reduction in scope is effectively a reduction to just the >> cases where the extension is mandatory, if that's what you intend to do >> then say so (expect pushback). >> > Yeah, I agree the assertive and restrictive terms are poorly defined. I was using terminology that this WG has been using for a while, but we can reword. > >> Please do not imply that any non-mandatory "additive" use-cases are >> viable. They are not. >> > > I agree with Viktor here. > > You could imagine enforcing a restriction you see in a DANE extension the > cert you get milliseconds later, but that's pretty useless given that an > attacker can just not send the extension. Let's just scope this to the > additive case. > > This mean "additive" mandatory or non-mandatory, I assume. Viktor opposes the latter case, I assume based on his (unproven) assertion that there will no incentive to deploy this. I don't agree. Lots of sites already publish DANE for HTTPS records even before browsers can use them (IETF, freebsd, debian, torproject, defcon, ripe, etc). Once code is implemented/deployed they will be using it. Shumon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters wrote: > On Sat, 28 Apr 2018, Shumon Huque wrote: > > [ not going to repeat my technical arguments here, just going to comment > on process ] > > First, there is no agreement that your reason for doing pinning, >> i.e. that DANE needs downgrade resistance against PKIX attacks >> is even valid. >> > > This is incorrect. From the replies to the consensus call on the list, > it actually weights in favour of _some_ kind of downgrade resistance. > This isn't clear to me at all. What I observe is that some folks who don't want pinning in the draft are okay with it being an optional separate extension (which they can ignore, but others that want it can implement). Sadly, only a handful of people are actually participating on the list. What you are ignoring is the many people who spoke up in person at IETF/London against pinning. Most of those folks are not speaking up on list now. So if we do put the pinning field in this draft, what I suspect will happen is that it will be discussed at some future IETF TLS WG meeting, and will be shot down, and we'll be back to square one again, and this draft will never make progress. Thus my pragmatic side is encouraging going in the direction of the new extension, which I believe has more chance of success. Shumon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Precluding bilateral opt-in for downgrade protection.
On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters wrote: > On Sat, 28 Apr 2018, Shumon Huque wrote: > > This can be clearly seen from various comments on >> list and at IETF/London, such as the point made many times that >> the original purpose of this draft was to add DANE as an additional >> possible authentication mechanism in TLS, not to position it as a >> mechanism that if available unconditionally trumps PKIX authentication.. >> > > This is actually upsetting. I can assure you that since the late 90's, > people were working on DNSSEC as an alternative for the webpki. I wrote > RFC 7901 as a building block for doing so, and that RFC is now the basis > of the format of the data in this document. It is an explicit goal of > _some_ people at IETF and has been for decades. What the motivation is > of the individual document editor is not relevant. Once the document > was adopted by the WG it became a document that needs to represent WG > consensus, not original author intent. > This is a case where clarifying the scope and limitations of the protocol from the outset would have been helpful. Many DNSSEC people I know who have followed this draft and participated in the much earlier discussions around DNSSEC stapling in certificates were acutely aware of lack of authenticated denial and its obvious implication that there was no downgrade resistance against PKIX. So I always assumed there was at least an implicit understanding of the scope. What greatly surprised me was that Viktor (and you) did not come to this realization until a few months ago (I believe that was shortly after I asked Viktor in private email to read the entire draft and I assume he came upon the text that described the issue, and the possibility of extending the protocol to include DoE later). We probably should have put this text in much earlier versions of the draft. Shumon ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday
On Wed, Jul 18, 2018 at 4:55 AM Eric Rescorla wrote: > > To the extent to which this is true, it's an argument that one should be > pinning at a different layer. > > (I've mentioned this in private email to some of you, but for broader input, I'm throwing it out on the list too.) On the topic of other layers .. At yesterday's WG meeting, Sam Weiler suggested that the pinning information could be conveyed via the DNS. That way you would not need new holes/fields in the TLS extension. Paul said it doesn't work. But Willem Toorop and I discussed it after the meeting, and think that it does. There could be a new DANEPIN RR type at the same TLSA record name (or TXT if we're opposed to new types) that could carry the pinning TTL and whatever else. This could be conveyed as just an additional record (and its signature) in the dnssec_chain extension data (which is designed as a sequence of RRsets), and authenticated in the same manner. It is of course vulnerable to stripping on first contact, but so is the entire TLS extension including any pinning fields, in the incremental deployment scenario. So it has no worse or better security properties. This could also express a generic DANE pinning capability that is not tied only to a TLS channel. Servers that don't want to be pinned would not advertise this record, and clients that don't implement pinning would just ignore this record if it is present in the chain. (It is probably possible to convey this DNS info in other ways, such as defining a new TLSA record usage field for pinning. So the TLSA RRset would include an additional record for pinning if needed. But I suspect there might be more arguments about such a design). This does need the dnssec_chain extension to allow authenticated denial chains to be delivered. Based on past list discussion, it appears to me that there is rough consensus to allow that, and the yet unpublished draft text in the github repo already includes it. Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt
E TLS > >protocol [RFC6698], and the additional protocol requirements outlined > >in [RFC7671]. > > Some discussion of UKS may be appropriate here, since there'll probably > be some day soon an update to RFC7671 that says that name checks are not > generally optional for DANE-EE(3), but as this protocol militates against > UKS attacks, the original policy of RFC7671 should stand despite any such > (near future) amendation. > Yes, I agree. > > > 7. Trust Anchor Maintenance > > > >The trust anchor may change periodically, e.g. when the operator of > >the trust anchor zone performs a DNSSEC key rollover. Managed key > >rollovers typically use a process that can be tracked by verifiers > >allowing them to automatically update their trust anchors, as > >described in [RFC5011]. TLS clients using this specification are > >also expected to use such a mechanism to keep their trust anchors > >updated. Some operating systems may have a system-wide service to > >maintain and keep the root trust anchor up to date. In such cases, > >the TLS client application could simply reference that as its trust > >anchor, periodically checking whether it has changed. > > Hence clients should signal servers whether they want the root DNSKEY > RRset, or already have a sufficiently fresh local copy. > [See previous discussion] -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt
On Wed, Mar 22, 2017 at 4:50 PM, Viktor Dukhovni wrote: > > > On Mar 22, 2017, at 10:56 AM, Melinda Shore < > melinda.sh...@nomountain.net> wrote: > > > > The draft could definitely benefit from > > additional review. > > I find it ironic that section 4 includes: > >The components of the authentication chain are built by starting at >the target record set and its corresponding RRSIG. Then traversing >the DNS tree upwards towards the trust anchor zone (normally the DNS >root), for each zone cut, the DNSKEY and DS RRsets and their >signatures are added. If DNS responses messages contain any domain >names utilizing name compression [RFC1035], then they must be >uncompressed. > > while at the same time there is ongoing discussion of *adding* compression > of the server certificate chain (as a TLS 1.3 extension). Would the > compression of server certificates also cover compression of the DNSSEC > chain extension? If so, perhaps this would be a belated moral victory > for DJB[1]. :-) > I think the reason for the last sentence quoted above is that DNS name compression is defined in terms of an offset from the beginning of the DNS message, and the draft as currently written uses a sequence of RRsets rather than a complete DNS message. I sympathesize with djb's critique. If DNS wasn't designed in the early 80's then perhaps we would have had something different. I supposed we could redefine name compression for this draft to use an offset from the beginning of the chain data. Does the proposed compression of certificate chains include extensions in the Certificate message also? If so, the DNSSEC chain extension would automatically be covered. Generally speaking, I would not be opposed to compressing the DNSSEC chain extension with a normal compression algorithm. Perhaps some empirical measurements might be useful to determine whether it yields significant enough savings. Large parts of the dnssec chain (signatures and keys) probably aren't terribly compressible, although I guess the same issue exists for certificate chains, and if it's worth it for the latter .. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
t). This trust anchor is also > > preconfigured in the TLS client, but including it in the response > > from the server permits TLS clients to use the automated trust anchor > > rollover mechanism defined in RFC 5011 [RFC5011] to update their > > configured trust anchor. > > I think this is wrong. The final DNSKEY RRSet does contain the the > preconfigured root key. However, it also contains other keys that > are used to sign the DS records. > Ok, yes, the rationale provided for including the trust anchor DNSKEY RRset is incomplete. As you say, it is also needed to authenticate the ZSKs which sign delegations. We'll update this text. > The client needs those keys in order to validate the chain, and those > keys are rotated every few months for root, instead of every N years. > Correct, and that's why the entire DNSKEY RRset is always delivered. > Furthermore, frequently the trust anchor is provisioned as a fake DS > record for the root. Validating with such anchor requires sending the > root DNSKEY. > Also true, and hence the entire DNSKEY RRset is always delivered. > Real-world zone data (omitted the cryptographic line noise, and added > some hilights): > > $ dig +dnssec -t DNSKEY . > [ stuff omitted ] 7) Section 4. Construction of Serialized Authentication Chains > > > The transport is "tcp" for TLS servers, and "udp" for DTLS servers. > > The port number label is the left-most label, followed by the > > transport, followed by the base domain name. > > So if this would be used with IETF-QUIC, the labels would be > _443._tcp, which is the same as one used by HTTPS, right? > I hadn't yet thought of this use case, but wouldn't it be _443._udp since QUIC runs over UDP? Perhaps a server operator that supports both TLS and QUIC, wants to have separate server credentials for each. And if not, they could alias one of the TLSA records to the other. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
On Tue, Jul 4, 2017 at 12:14 PM, Viktor Dukhovni wrote: > > > On Jul 4, 2017, at 11:33 AM, Shumon Huque wrote: > > > > Yes, in fact the previous sentence to the one you quoted did say this > more or less: " ... return a serialized authentication chain in the > Certificate message associated with the end entity certificate being > validated ". I would propose rewording that a bit and removing the last > quoted sentence entirely: > > > >Servers receiving a "dnssec_chain" extension in the ClientHello, and > >which are capable of being authenticated via DANE, SHOULD return a > >serialized authentication chain in the extension block of the > Certificate > >message containing the end entity certificate being validated, using > the > >format described below. > > Why the end-entity certificate, and not the final certificate > sent by the server? With anything but DANE-EE(3) the TLSA > records can't be processed against the server's certificate > message until *all* the server certificates have been received. > I'm not in principle opposed, but intuitively it makes most sense to associate the DNSSEC chain with the certificate being validated. The other logical place this might have been placed is Encrypted Extensions. But that again precedes the Certificate message, so doesn't address your buffering up concern. Also if DANE-EE turned out to be the common use case, it helps right? Cause the validator doesn't care about the rest of the certificate chain, and can authenticate the EE cert right away. > So instead of squirreling away the DNS data while waiting for > all the server certificates to arrive, it may make more sense > to receive the TLSA records (and associated signatures, CNAMEs, > DNAMEs, ...) once all the server certificates have been received. > > Of course either way one still buffers all the server certificates, > so buffering the TLSA records is not a major issue. It's just that > I don't see a compelling argument for sending the TLSA records with > the EE certificate. Perhaps send them with any of the server > certificates, it probably makes no difference which... > Ok. Let's see if anyone else chimes in with opinions on this .. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara
wrote:
> On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote:
>
> >
> > Since the ordering is a SHOULD on the server side, the client has to
> check
> > and perform canonical re-ordering if necessary anyway, before computing
> and
> > validating the signature. If this were a MUST, a stronger case could be
> > made that this recommendation saves the client some work.
> >
> > Personally, I would be fine with taking out the recommendation for the
> > server to canonically order the records. DNSSEC validators (the client
> end)
> > are required to reconstruct the canonical form and ordering of the RRset
> > (see RFC 4035, Section 5.3) before validation, so unless there is a
> > compelling rationale for deviating from this, we shouldn't.
> >
> > Section 6 ("Verification") essentially says to do validation according to
> > RFC 4035, which covers all of this, and we were planning on leaving it at
> > that -- rather than replicating text that just restates DNSSEC validation
> > logic that is normatively defined elsewhere.
>
> I think either this should be strengthened or taken out entierely.
> Right now it is "the worst of both worlds".
>
My proposal is to remove the recommendation that the server SHOULD order
records in an RRset. And refer to the normative DNSSEC validation algorithm
for the client. That should take care of this.
>
> > (Perhaps RFC 5155 should also be mentioned now that this spec
> accommodates
> > negative proofs associated with wildcards and thus has to deal with
> NSEC3).
>
> Oh yes. AFAICT (since there is always data):
>
> - If the record is not a wildcard, then no NSEC nor NSEC3 records are
> needed.
>
Correct.
> - If the record is a wildcard, then one NSEC or NSEC3 record that
> denies the sibling of source that is the ancestor of the QNAME.
>
The client first needs to determine that a wildcard DNS record was matched
- this can be deduced from the the label count field in the RRSIG record
being less than the label count in the QNAME. It then needs to authenticate
NSEC/NSEC3 records that prove the following facts: (1) that there is no
exact match of the QNAME and (2) that no closer wildcard could have
matched. Often the same NSEC/NSEC3 record can prove both facts.
> > > Also, 'RRsig record' or 'RRsig records'? IIRC, if ZSK is being rolled
> > > (and for DNSKEY, if KSK is being rolled), there will be two RRsig
> > > records for one RRtype.
> > >
> >
> > Good catch. RRsig records (or maybe RRsig RRset).
>
> Maybe I'm just unfamilier with DNS, but I think RRsig RRset might be
> interpretted as set of RRsig records in some name (which is very much
> wrong interpretation here).
>
An RRset is defined as the set of records that share the same name, type,
and class. So an RRsig RRset should cover signatures produced by different
keys for the same RRset. But if this sounds confusing, I'm okay with "RRsig
records".
> > 7) Section 4. Construction of Serialized Authentication Chains
> > >
> > > > The transport is "tcp" for TLS servers, and "udp" for DTLS servers.
> > > > The port number label is the left-most label, followed by the
> > > > transport, followed by the base domain name.
> > >
> > > So if this would be used with IETF-QUIC, the labels would be
> > > _443._tcp, which is the same as one used by HTTPS, right?
> > >
> >
> > I hadn't yet thought of this use case, but wouldn't it be _443._udp since
> > QUIC runs over UDP? Perhaps a server operator that supports both TLS and
> > QUIC, wants to have separate server credentials for each. And if not,
> they
> > could alias one of the TLSA records to the other.
>
> Yes, QUIC runs over UDP. However, IETF-QUIC will be TLS 1.3, not DTLS.
>
You mean IETF QUIC will reuse the TLS 1.3 handshake mechanism right? But
it's still a distinct transport from TLS 1.3 I assume. (I'm a QUIC newbie -
feel free to correct me).
The statement in the draft that the "_udp" label is for DTLS servers might
be too restrictive, and perhaps it should be expanded to include other
secure transports that run over UDP. The TLSA spec (RFC 6698) today only
defines 3 transport labels _tcp, _udp, and _sctp. I'm wondering whether
that needs to be expanded to include things like tls/dtls/quic, and whether
it needs an IANA maintained registry for extensibility.
--
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
On Tue, Jul 4, 2017 at 4:50 PM, Ilari Liusvaara wrote: > On Tue, Jul 04, 2017 at 01:18:05PM -0400, Shumon Huque wrote: > > On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote: > > > > > > > > > An RRset is defined as the set of records that share the same name, type, > > and class. So an RRsig RRset should cover signatures produced by > different > > keys for the same RRset. But if this sounds confusing, I'm okay with > "RRsig > > records". > > RRsig is special in that it is subtyped in RRdata. I don't know if > concept of "RRset" is redefined for RRsig to take that into account. > > I.e., does RRsig RRset include RRsig's for any possible A records (which > are very much not interesting here)? > I think we need to say the set of RRsig records that "cover" the type in question." Shumon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
On Wed, Jul 5, 2017 at 12:30 PM, Jim Reid wrote: > I’ve got a few concerns/issues with the document. > Hi Jim, I largely agree with the responses Viktor gave in a previous message. I'll comment on the last point where he did not: > 6) The draft doesn't seem to take account of key rollovers when DNS data > will be signed by two or more keys. Zone signing keys are missing from the > examples too. These might well have been omitted for cosmetic reasons. IMO > they need to be included in the final document to illustrate what > implementers can expect to find when the DNS returns signed data. > I assume you're referring to the examples in Appendix D (Test Vectors)? These are working examples that implementers can test code against. But it looks like the testbed involved in these examples uses combined signing keys (i.e. ones that are both the zone's secure entry point and the ZSK). Perhaps we should use an example with the KSK/ZSK split to make them look more like the real world. Let me discuss with Willem Toorop (co-author) who generated these ... -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
On Wed, Jul 5, 2017 at 1:12 PM, Viktor Dukhovni wrote: > On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote: > > > 3) Something should be said about algorithm agility. We can be reasonably > > sure web browsers, DNS servers, smart phones and so on will generally > have > > up-to-date DNSSEC validators and/or TLS code. Some TLS clients -- fire > > and forget embedded systems, IoT devices, etc -- might never get updated > > once they're deployed. If these clients use their own DNSSEC validators, > > they will be screwed when/if DNSSEC drops SHA1 signatures (say) or adds > > a new flavour of ECC or even an all-new signing protocol. > > SHA2 is already defined and widely used for DS records. The X25519 > and X448 EC algorithms are already defined (or will be by the time > this draft becomes an RFC). RFC 8080, defining Ed25519 and Ed448 for DNSSEC, is already published. There are already some early implementations (PowerDNS and NLnet Labs' Unbound; maybe others). > So there's not much churn on the > immediate horizon. Devices doing all the validation locally will > need software updates roughly once a decade (DNS parameters change > slowly). A secure channel to a *trusted* resolver would avoid the > problem, but trustworthy off-device resolvers are very unlikely to > be ubiquitous. > Regarding churn, I expect we'll have several post quantum signature algorithms for DNSSEC in the 5 to 10 year horizon. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
On Fri, Jul 7, 2017 at 10:11 AM, Jim Reid wrote: > > > On 5 Jul 2017, at 18:12, Viktor Dukhovni wrote: > > > > On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote: > > > >> 1) There probably needs to be clearer guidance about the use cases for > >> this extension and the trade-offs between TLS clients doing DNSSEC > >> validation for themselves instead of sending DNS lookups to a validating > >> resolver server. How does an application developer decide which approach > >> would or wouldn't be appropriate? > > > > On today's Internet, DNSSEC is not generally available to end-user > > devices. There are too many "last mile" problems. Thus, while > > direct acquisition of DANE TLSA records works for (e.g.) dedicated > > SMTP servers, any end-user application that wants to do DANE TLS > > needs to use the proposed extension. > > I am too painfully aware of those last mile issues. > > IMO the draft could be clearer about the fact it’s aimed at TLS clients > that don’t have access to or a trust relationship with a validating DNS > resolver. It is not aimed solely at those clients. The intro mentions 3 things: (1) TLS clients don't need to do any additional DNS lookups for DANE/DNSSEC - the latency issue, (2) TLS clients don't need to deal with breakage caused by middlebox/last mile issues if they tried to do those lookups, and (3) they don't have secure access to a validating resolver. If an application has any subset of these issues, it might be candidate user of this extension. > > Perhaps you're asking whether once the relevant records are obtained, > > their validation should be via library calls to a suitable API, or > > via a suitable protocol to the local resolver? > > No. I couldn’t care less about API issues or how the RRSIGs get validated. > They’re implentation details for the implementation detail. I am uneasy at > the prospect of every TLS client application include what will be > essentially its own validating DNS resolver when there could/should be one > of these already running on the device itself. > Maybe some day all end user machines will have a validating resolver, but this isn't remotely close to a reality today. > > Except that the records will be warm in the server's cache, since > > many clients will be asking it for the *same* data. The same is > > not as likely to be true at the client. So there is indeed a likely > > latency reduction in farming out the lookups to the server. > > OK. > > It might be helpful to explicitly say “TLS server” rather than “server” to > avoid confusion or ambiguity. Sometimes this is obvious from the context. > But at other places in the draft “server” could be read as “DNS server”. > Ok, we can look through the text and disambiguate where needed. > >> 4) It's not clear if TLS clients can or should cache the DNS data (and > >> the resulting validations?) returned though this extension. > > > > The server will return TTLs, and caching per those TTLs is no less > > appropriate than it is in DNS generally. > > Is there some reason why this isn’t in the draft? We've had this discussion numerous times over the life of this draft, and there was never any consensus for the client caching or not. An implementation could have the client cache the data, and only validate the portion of the chain that it needs to, without any wire protocol change. I'm okay with mentioning that possibility. IMO, the real gain from having the client cache data, is that the server could then potentially send a much smaller DNSSEC chain. But this requires the client to signal what they've cached, and makes the protocol more complex. I would prefer to leave that to a future revision of the spec, after we've gained some operational experience with the current one. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
On Fri, Jul 7, 2017 at 11:34 AM, Jim Reid wrote: > > > On 7 Jul 2017, at 16:06, Shumon Huque wrote: > > > > IMO, the real gain from having the client cache data, is that the server > could then potentially send a much smaller DNSSEC chain. But this requires > the client to signal what they've cached, and makes the protocol more > complex. I would prefer to leave that to a future revision of the spec, > after we've gained some operational experience with the current one. > > Shumon, I think the biggest gain would be fewer RRSIGs for the client to > validate. Having the server send a smaller DNSSEC chain (and perhaps add > something to the protocol for a client to signal that) probably won’t have > the right cost/benefit optics. YMMV. It would be a Good Thing if a TLS > client didn’t need to revalidate everything in the chain for tlsa.foo.com > after closing and reopening a TLS session to that end-point or it could > start at the previously validated delegation for .com when the TLS server > returned the full chain for tlsa.bar.com. > > As you hint at, it would be good to get more data and operational > expertise. > Okay, absent any strenuous objections, I propose that we mention that the client may cache data from the chain. For the case of a TLS client re-connecting to the same end point, most likely TLS session resumption would be used (thus dnssec_chain re-validation wouldn't be needed) so this optimization doesn't gain anything. But yes, it would help save the client some signature validation work in the case of tlsa.foo.com to tlsa.bar.com. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
On Fri, Jul 7, 2017 at 11:59 AM, Benjamin Kaduk wrote: > On 06/28/2017 04:15 PM, Joseph Salowey wrote: > > This is the working group last call for > draft-ietf-tls-dnssec-chain-extension-04. > Please send you comments to the list by July 12, 2017. > > > Just a couple minor things I don't remember being mentioned already that I > noticed in a quick read: > > When section 3.4 mentions that "this document describes the data structure > in sufficient detail that implementors if they desire can write their own > code to do this", it seems that this really on makes sense when the "this" > is for the encoding side, not the decoding side. That is, in that we > expect future DNS clients to continue to process responses in the current > format, but future DNS servers might generate responses that cannot be > properly decoded just following this document. (E.g., what would happen if > NSEC5 became popular?) > I think it's best to take that sentence out. It's a remnant of much earlier versions of the draft where we did describe the decoding (and validation) side in more detail, whereas now a lot of the client side processing is being referred to DNSSEC specs. Regarding future DNSSEC protocol enhancements that may necessitate format and protocol processing changes, maybe it's best to defer those to future revisions of the spec. But feel free to propose any specific wording on this topic for inclusion. (NSEC5 adoption in DNSOP is still very much an open question. The other possible enhancement that might need to be considered in the future is records related to key transparency - "CT for DNSSEC", which could happen someday.) > In section 8: > >Mandating this extension for Raw Public Key >authentication (where there are no X.509 certificates) could employ >configuration mechanisms external to the TLS protocol > > this sentence structure is a little confusing; it might be better to say > something like "If needed, configuration mechanism external to the TLS > protocol could be used to mandate the use of this extension for Raw Public > Key authentication". > > -Ben > > Yes, your suggested text sounds much better. We can incorporate that. However, there is larger concern that I have with section 8 that probably deserves working group discussion. This section might imply that there is a (protocol resident) way to mandate the use of this extension, but I don't think there is an easy way. Even in the case of X.509 certificates, the TLS feature extension can only dictate the delivery of this extension when the client has connected to the right server presenting that certificate. A TLS client misdirected to a rogue TLS server (e.g. via DNS spoofing, a routing attack, or other means) that has fraudulently acquired a public CA issued certificate for the legitimate server name, could be induced to establish a (PKIX) verified connection to that rogue server that precludes DANE authentication, when in fact it was available. Some TLS applications may desire to mandate DANE authentication where available, and protect themselves against malicious or tricked CAs. What is the best way to accommodate them? TLS clients could keep a whitelist of DANE servers, which doesn't scale very far; they could use TOFU/HPKP like methods: add DANE supporting sites to a whitelist dynamically as they are seen, etc. Some other applications use the presence of an authenticated TLSA record to enforce DANE authentication (RFC 7672 for SMTP STARTTLS). The last time this was discussed in the context of tls-dnssec-chain, it was argued that this "mandatory use" was not a semantic that the generic TLSA record provides, so only specific applications should specify that behavior. But if a specific TLS application using this extension did want to specify this behavior, how could it happen? In a hypothetical world where all TLS clients & servers understood this extension, we could have required the TLS server to either (1) present the dnssec_chain for their TLSA record, or (2) present a dnssec_chain that demonstrates that there is no secure TLSA record, or that there is no secure delegation to the zone. I think this would solve the problem, but this isn't practical any time soon (or perhaps ever). I'm not suggesting that we need to come up with a solution for this, but I believe the issue probably needs some sort of mention somewhere (in Security Considerations?). -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
On Fri, Jul 7, 2017 at 3:13 PM, Tom Ritter wrote: > As a note, I didn't see anything in this draft (from a quick read) > that precludes any of DANE's Certificate Usage, Selector, or Matching > Type fields. If that's not the case, perhaps someone can correct me. > Yes, that's correct. Is there any reason it should? TLS applications are free to preclude the use of DANE parameters, but a more general purpose protocol I feel probably should not. The draft does refer several times to RFC 7671 (DANE updates and operational guidelines), which has some recommendations which ought to be followed. >A client must not be able to force a server to perform lookups on >arbitrary domain names using this mechanism. Therefore, a server >MUST NOT construct chains for domain names other than its own. > > What about the reverse? Do we care about a server tricking a client > into priming its DNS cache? > -tom > Yes, we want to avoid that, but I would expect that any sane client implementation, as a basic precaution, would only accept a DNSSEC chain corresponding to the TLSA name that it expected to see. If the server presented anything else, it would not be considered invalid. Similarly, if the chain included embedded unexpected extraneous records, I would expect the client implementation to ignore those (or even invalidate the whole chain if it wanted to be more draconian). If necessary, we could have explicit text about this. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
On Fri, Jul 7, 2017 at 7:05 PM, Viktor Dukhovni wrote: > > Once the client obtains a validated TLSA RRset for the service > endpoint, it may (up to the TTLs of the provided records, validated > to conform to the max ttl of the RRSIGs and not exceed the RRSIG > expiration) simply not omit the extension in subsequent requests, > and validate the server certificate per the cached TLSA RRs. > ( assumed typo: s/not omit/omit/ ) This is quite a reasonable and simple optimization, and I think we should document it in the draft. It may often be short circuited by TLS session resumption, but it's so simple that it's probably worth doing. Thanks! -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On Sat, Jul 8, 2017 at 5:16 PM, Nick Sullivan wrote: > Putting questions of whether or not this belongs as a working group > document, I think there are some necessary requirements for > intra-datacenter passive decryption schemes that are not met by this draft. > > Specifically, any passive decryption scheme should the following two > properties: > 1) Both server and client must explicitly opt-in > 2) A third party should be able to tell whether or not this feature is > enabled by observing the stream > > These two requirements protect services on the wider Internet from being > accidentally (or surreptitiously forced to be) subject to unauthorized > decryption. > I absolutely agree. What you likely want is something similar to TLS 1.2 session tickets with > centrally managed session ticket keys. The client would advertise support > for "passive session decryption" in an extension and the server would > return an unencrypted extension containing the session keys encrypted by a > server "passive decryption key". The passive decryption key would be > managed in the same way as the static DH key in this draft: rotated > frequently and synchronized centrally. > This is the best proposal I've seen so far. What is the problem of publishing a scheme like this as an Informational RFC? After all, we can cite many examples of protocols described in Informational RFCs that are widely deployed by industry. If the proponents of this draft think it critical that this needs formal IETF endorsement as a standard, then I believe they ought to be also working on persuading the IETF to withdraw or at least backtrack on some of our previous statements (such as RFC 7258, which declared that IETF protocols need to have technical countermeasures to prevent pervasive monitoring). I doubt that we will be able to get consensus on IETF endorsement. Speaking only for myself, I am against the IETF/TLS wg endorsing a protocol that degrades the security of the TLS protocol. But I am perfectly fine with publishing it as Informational document. -- Shumon Huque ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Re: Transparent TLS Client Auth (t2CA)
Phillip, Can you review the DANCE documents and see if they can satisfy your use case? https://datatracker.ietf.org/wg/dance/documents/ You could also start a thread on the DANCE wg mailing list. At first glance, I can't see why the DANE TLS client auth protocol described there could not accommodate Bluesky/AT protocol handles, but perhaps you can do a deeper review. It might also be useful to describe the use case in the DANCE architecture doc (which describes the set of other use cases we had originally envisioned). This set of docs is currently in working group last call. Shumon. On Wed, May 21, 2025 at 10:15 AM Phillip Hallam-Baker wrote: > Thanks! I had forgotten about that spinning out. I was coming to this from > the OAUTH frame and suddenly realized TLS client auth could be a better > option. > > It certainly looks like DNS Handles makes that model look a lot clearer. > The frame that we were given for Internet accounts is 'al...@example.com', > the account being provided by an Internet service. OAUTH originally fit the > same model only it is an account with an authentication service. > > @alice.example.com is a different frame in which Internet accounts are > represented directly in the DNS. It is a model a lot of people have > resisted but there are 35 million users already and growing. > > > On Wed, May 21, 2025 at 8:57 AM Ben Schwartz wrote: > >> This sounds a bit like draft-ietf-dance-client-auth. >> >> --Ben Schwartz >> -- >> *From:* Phillip Hallam-Baker >> *Sent:* Tuesday, May 20, 2025 10:44 PM >> *To:* tls >> *Subject:* [TLS] Transparent TLS Client Auth (t2CA) >> >> I have floated parts of this scheme in OAUTH and DANE. As we all know, >> TLS does Client auth in theory but the implementations are unusable for two >> reasons: 1) Issue of client side certs is a pain 2) The user interface >> asking the user to select >> I have floated parts of this scheme in OAUTH and DANE. >> >> As we all know, TLS does Client auth in theory but the implementations >> are unusable for two reasons: >> >> 1) Issue of client side certs is a pain >> 2) The user interface asking the user to select a certificate. >> >> Both problems could potentially be addressed by the emerging DNS handles >> infrastructure. At present, the authentication is OAUTH2 based. But TLS >> Client Authentication under a certificate validated under the DNS handle >> would be cleaner. >> >> So, I am looking for people interested in a side meeting in Madrid. >> >> Here is my current sketch: >> >> User gets handle from DNS Handle provider who (usually) also runs an >> OAUTH2 service under the ATprotocol profile and a private CA for the user. >> >> The root of the private CA is bound to the DNS zone by a TXT or TLSA >> record. >> >> Each device the user wants to use with their DNS handle gets issued its >> own client cert. >> >> Users can have multiple personas and the browser selects the certificate >> the user has assigned to the site asking for authentication. >> >> >> Net is that the user gets to authenticate to any site (supporting T2CA) >> under the DNS Handle and persona they have selected for their site without >> any additional hassle. >> >> >> ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
