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

[Eric Rescorla <[e-mail]>]

On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque <[e-mail]> wrote:

> On Wed, Feb 7, 2018 at 9:34 AM, Eric Rescorla <[e-mail]> wrote:
>
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-tls-dnssec-chain-extension-06: Discuss
>>
>
> Thanks Eric for your detailed review and comments.
>
> > This draft seems generally sound, but I believe there are pieces that
> > are still underspecified. These should be easy to fix.
> >
> > the Signer's Name field in canonical form and the signature field
> >    excluded.
> >
> > 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.


We deliberately didn't include in this document a detailed description
> of the DNSSEC validation algorithm. The algorithm is sufficiently
> complicated (and lengthy to describe) that those details are best left
> to the relevant DNSSEC RFCs. I think it would be helpful to point
> specifically to which documents and sections here though (mainly
> RFC 4035 Section 5, and RFC 5155 Section 8). We could also include a
> brief synopsis of the algorithm and refer to these documents for
> further details.
>

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


Otherwise, can you suggest more specifically what level of additional
> detail you'd like to see in this document?
>

See above.


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


>
> >    abort the connection, the server uses the domain name associated with
> >    the server IP address to which the connection has been established.
> > IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple
> names for the same IP.
> >
>
> Yes, indeed. This sentence is dealing with the case where the client has
> not indicated to the server which name it wants to connect to, so the
> server is basically guessing anyway. Perhaps we could reword this to say
> something like, "the server picks one of its configured domain names for
> the associated IP address".
>

Yes, that would be fine.


(This situation could also have been avoided by mandating client use of
> the SNI extension).
>
> >    DNSSEC authentication chain extension from a server, SHOULD use this
> >    information to perform DANE authentication of the server.  In order
> >    to do this, it uses the mechanism specified by the DNSSEC protocol
> >
> > IMPORTANT: What happens if the DANE validates but the cert is revoked
> > or alternately the cert validates but DANE does not?
>
> This depends on the mode of DANE in use (i.e. the Certificate Usage
> field of the TLSA record). If I recall correctly, this should all be
> covered in detail in RFC 7671 ("DANE Updates and Operational Guidance").
>
> * With DANE-EE, only the EE certificate is matched against the
>   certificate data/hash in the TLSA record. There is no CRL/OCSP
>   style revocation. Revocation would be performed by removing the
>   TLSA record from the DNS.
>
> * With DANE-TA, the indicated CA certificate referenced in the TLSA
>   record may have advertised revocation mechanisms that need to be
>   consulted.
>
> * 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.


Would you like us to discuss this in the draft? Or is referring to
> RFC 7671 sufficient?
>

I think you should discuss it in the draft as it is relevant to TLS
implementation.



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.


 note, I believe most envisioned use cases of this draft
> will be for the DANE-* modes. The PKIX constraining modes have the
> issue that for them to work securely, the client must be able to
> confirm the presence of DANE records, which leads to the issues of how
> to mandate use of this mechanism (Section 8 of this document).
>

Yes, I don't think those modes are useful here.


The TLS version-specific protocol elements involved in delivering this
> extension are described in Section 3. For the Introduction section from
> which the above text is excerpted, I would suggest the following rewrite:
>
>    The extension described here allows a TLS client to request that
>    the TLS server return the DNSSEC authentication chain corresponding
>    to its DANE record. If the server is configure for DANE ...
>

Yes, this is fine.


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


>    arbitrary domain names using this mechanism.  Therefore, a server
> >    MUST NOT construct chains for domain names other than its own.
> > "its own" is a bit fraught, as servers may not actually know all their
> domain
> > names, at least at the TLS layer.. Can you be more specific about what
> the
> > server algorithm is.
>
> To implement this specification, the TLS layer does need to have
> preconfigured knowledge of the names for which it has DANE records.
>
> This text is also a bit imprecise and should be improved anyway. The
> server doesn't construct chains for its own domain name, but rather
> the TLSA record name corresponding to that domain name. This domain
> name is either one explicitly indicated by the client via SNI (assuming
> that the indicated name is one the server recognizes as its own),
> or if no SNI is provided, one that the server picks from its known
> set of names (as discussed previously).
>
> 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.



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



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

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.


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

-Ekr


> Shumon Huque
>
>