Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-https-tal-07: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

(just one note inline)

On Tue, Apr 30, 2019 at 10:36:16AM +0200, Tim Bruijnzeels wrote:
> Hi Benjamin,
> 
> My apologies. While updating -07 based on the review comments I found that I overlooked your response.
> 
> See response in-line, I am including these in the -08 that will follow shortly.
> 
> > On 10 Apr 2019, at 05:27, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-sidrops-https-tal-07: No Objection
> > 
> > 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-sidrops-https-tal/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Thank you for keeping the diff from RFC 7730 tidy!
> > 
> > Abstract
> > 
> >   their CA certificate.  In particular it allows TAs to change the set
> >   of Internet Number Resources included in the RFC3779 extension of
> >   their certificate.
> > 
> > Neither "Internet Number" nor "Number Resources" appears in RFC 3779 that I
> > can see.  (On a quick skim, I'm still not sure if we mean AS number or IP
> > address/prefix.)
> > 
> 
> ack, clarified.
> 
> 
> > Section 2.1
> > 
> >   the trust anchor per se.  In the RPKI, certificates contain
> >   extensions that represent Internet Number Resources (INRs) [RFC3779].
> > 
> 
> good point, I am used to this term so I took it for granted. Now clarified.
> 
> 
> > (As above, I don't see INRs mentioned in RFC 3779.)
> > 
> > Since comments are new in this rev of TAL, do we want to caution consumers
> > that implementations may not necessarily support comments yet?
> 
> I added the following section:
> 
> 1.2. Changes from RFC7730
> 
> The TAL format defined in this document differs from the definition in [RFC7730] in that: 
> 
> 	• it allows for the use of the HTTPS scheme in URIs; and
> 	• it allows for the inclusion of an optional comment section.
> 
> Note that current Relying Parties may not support this new format yet. Therefore it is RECOMMENDED that a Trust Anchor operator maintains a [RFC7730] TAL file for a time as well until they are satisfied that RP tooling has been updated.
> 
> 
> > 
> > Section 2.3
> > 
> >   The trust anchor MUST contain a stable key.  This key MUST NOT change
> >   when the certificate is reissued due to changes in the INR
> >   extension(s), when the certificate is renewed prior to expiration, or
> >   for any reason other than a key change.
> > 
> > (This seems a bit tautological...)
> > 
> >   If an entity wishes to withdraw a self-signed CA certificate as a
> >   putative trust anchor, for any reason, including key rollover, the
> >   entity MUST remove the object from the location referenced in the
> >   TAL.
> > 
> > Certain classes of attacker could continue to publish the last-known
> > certificate as a trust anchor and prevent this withdrawl from taking
> > effect; we should probably cover that in the security considerations.
> > 
> 
> see below 2.4, or am I missing another point here?
> 
> > Section 2.4
> > 
> > We say that it's RECOMMENDED to have different domains (so as to get
> > different IP addresses) but this example shows only a single domain.
> > 
> > Section 4
> > 
> >   Note that a Man in the Middle (MITM) cannot produce a CA certificate
> >   that would be considered valid according to the process described in
> >   Section 3.  [...]
> > 
> > I think the key part is that the attacker cannot produce a *new* CA
> > certificate that differs from a legitimate one, but they can MITM the HTTPS
> > connection and present a legitimate (but potentially stale) CA certificate.
> 
> We have this (slightly re-worded text) in the Security section:
> 
> Note that, although a Man in the Middle (MITM) cannot produce a CA
> certificate that would be considered valid according to the process
> described in Section 3, this attack can prevent that the Relying Party
> learns about an updated CA certificate.

I think (but am only about 80% sure) that we want "updated or removed"
here.  So add it if it makes sense to you, and if not, don't worry about
it.

Thanks,

Ben

> This does not go on to clarify the consequences of such possible attacks, but I believe this is sufficient warning to implementers.
> 
> 
> > 
> >   o  DNS names in Repository Server certificates SHOULD NOT contain the
> >      wildcard character "*".
> > 
> > Would a Relying Party ever reject the HTTPS connection (and thus, the
> > delivered TA) if a wildcard certificate is presented for the HTTPS
> > connection?
> 
> This is most likely controlled by the HTTPS client library used by the RP software. In some cases it may not be possible to tweak the behaviour. Therefore I think the SHOULD NOT is the right level. 
> 
> 
> > 
> > Section 5
> > 
> >   This TAL does not directly provide a list of resources covered by the
> >   referenced self-signed CA certificate.  Instead, the RP is referred
> >   to the trust anchor itself and the INR extension(s) within this
> >   certificate.  This provides necessary operational flexibility, but it
> >   also allows the certificate issuer to claim to be authoritative for
> >   any resource.  Relying parties should either have great confidence in
> >   the issuers of such certificates that they are configuring as trust
> >   anchors, or they should issue their own self-signed certificate as a
> >   trust anchor and, in doing so, impose constraints on the subordinate
> >   certificates.
> > 
> > Are there any external databases that a RP could consult to affect the
> > decision of whether to believe that a TA should actually be claiming the
> > indicated resource(s)?  (It would be a bit silly, given that this is the
> > RPKI already, but still...)
> 
> I think this is out of scope for this document. But the RIRs do publish their stats here on the NRO website:
> https://www.nro.net/about/rirs/statistics/
> 
> 
> 
> 
> 
> > 
> > 
> > _______________________________________________
> > Sidrops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sidrops
>