Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Shumon Huque <[e-mail]>]

Sorry for my belated follow-up. Was temporarily overwhelmed by the
day job ..


On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla <[e-mail]> wrote:
> On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque <[e-mail]> wrote:
>
> > > IMPORTANT: I'm not sure that this is actually sufficient to allow an
> > > independent implementation without referring to the other documents. I
> > > mean, I think I pretty clearly can't validate this chain from the
> > > above.
> >
> > We could add an explicit reference here to the DNS protocol document(s)
> > and sections within them that define the canonical form of domain
> > names (RFC 4034, Section 6 probably is the best reference), or even
> > excerpt the relevant text from that document. Would this satisfy your
> > concern?
> >
>
> Well, and remove your text about it being possible to implement solely
from
> this
> document.

Yes, I agree, we need to remove that.


> It's not the algorithm. I don't believe this document is sufficient to
> parse the
> structure.


Okay, got it. For people that have already implemented this, I think
there has been an implicit understanding that the format of the chain
data is a sequence of concatenated wire format RRs exactly as they appear
in a DNS message section (with one injunction against doing DNS name
compression). I'll write some text to make this more explicit and describe
the format in more detail with references to the appropriate DNS specs.

This is also the format that is readily generated and consumed by some
DNS libraries and the Intro section of this document has the following
assumption: "... (assuming that the data will be prepared and consumed
by a DNS-specific library) ..."


> > Similarly, although I think this is enough to break apart the
> > > RRSETs into RRs, it doesn't tell me how to separate the RRSETs from
> > > each other. I think you need to either make this a lot more complete
> > > or alternately stop saying it's sufficient.
> >
> > We can add some text about this. Basically the client would scan the
chain
> > reading RRs and group adjacent RRs that share the same RR name, type,
and
> > class into a distinct RRset.
> >
>
> I'd have to review your text to know if it was sufficient.

Ok. I'm working on text for this ..

> >
> > * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation
mechanisms
> >   need to be consulted and honored.
> >
>
> Well, neither of these modes is useful here, as an attacker will simply
> ignore the
> extension.

Just to confirm, I assume the attacker here is an entity attempting
to impersonate the TLS server (with presumably valid PKIX credentials).
If so, yes it can trivially ignore the extension, but this is the case
for any DANE usage mode (not just the PKIX constraining ones).

As discussed in Section 8, the protocol as currently specified really
only allows opportunistic DANE authentication, unless some mechanism
external to TLS is employed to mandate DANE usage. (The protocol could
be extended to require TLS servers to also provide a DNSSEC proof that
they don't have a signed TLSA record, but that could only be deployed
in a TLS application system where all servers supported this extension).


> On your last case, "cert validates but DANE does not", I assume
> > you mean the cert validates via PKIX but not DANE? I'm not sure this
> > is explicitly discussed in any other DANE document but presumably
> > if DANE is being used, DANE must validate.
> >
>
> Why would that be so? This only is useful in DANE-EE and DANE-TA modes in
> the first place, and so there is a possibilityt aht PKIX is valid.

I think Viktor's earlier reply to this thread goes into detail about
possible
client behaviors here and what we might recommend (which seems reasonable
to me). I'll follow-up there.


> > 3.1.  Protocol, TLS 1.2
> > > You should probably provide some guidance about whether the server
> > should still
> > > provide the whole X.509 chain to the client. I believe with these
> > semantics,
> > > the server cannot tell which DANE mode the client wants and therefore
> > has to
> > > provide the entire chain.
> >
> > Sure, we can elaborate.
> >
> > The DANE mode to be used is advertised by the server in its TLSA
record(s),
> > so the server already knows whether it needs to return the X.509 chain.
> > If the TLSA RRset has only DANE-EE, then only the end-entity certificate
> > needs to be returned. If DANE-TA, then only the chain from the TA cert
to
> > the
> > EE needs to be returned. If using the PKIX modes, then yes, the entire
> > X.509
> > chain has to be sent.
> >
>
> The problem is that the client is the decider about what it wants to
> accept, not
> the server.

My comment was about what DANE mode choices the server is offering to
the client. Certainly, the client can decide whether it wants to use
DANE or not, and whether it wants to fallback to PKIX. The protocol
should probably not be proscriptive here, and allow different TLS
applications (or configurations of such applications) to make choices.
But maybe there 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.


> >
> > The purpose of the MUST NOT sentence here is to prevent clients from
> > using the TLS server to lookup arbitrary domain names.
> >
>
> OK. Well, perhaps some better text is needed here.

Fair enough. I'll propose some new text to make this clear.


> >    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.


> > >              . 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?
> >
>
> You provided an algorithm for how to construct responses. How is it
> different from the
> algorithm that the  name server would  use to respond to a query for the
> TLSA record.

Well, the algorithm the DNS server (specifically a DNSSEC aware
resolver) uses is the DNS iterative resolution algorithm - the TLS server
would just treat that as a blackbox (unless it implemented its own
resolver).

I think the more important question is how the TLS server issues a
sequence of queries to the resolver to obtain the data it needs to
construct
the dnssec chain, and then extracts the corresponding RRsets from the
responses to those queries.

Section 4 (paragraphs 4 through 6) describe that process. Again, we could
go into more detail here, but we were working with the assumption in the
intro ( ".. the data will be prepared and consumed by a DNS-specific
library.")


> > >    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)?

Shumon.