RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Reported (2)

RFC 6125, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", March 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 5654
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Owen Friel
Date Reported: 2019-03-13

Section 7.4 says:

   A more recent approach, formally specified in [TLS-EXT], is for the
   client to use the TLS "Server Name Indication" (SNI) extension when
   sending the client_hello message, stipulating the DNS domain name it
   desires or expects of the service.  The service can then return the
   appropriate certificate in its Certificate message, and that
   certificate can represent a single DNS domain name.

It should say:

   A more recent approach, formally specified in [TLS-EXT], is for the
   client to use the TLS "Server Name Indication" (SNI) extension when
   sending the client_hello message, stipulating the DNS domain name it
   desires or expects of the service.  The service can then return the
   appropriate certificate in its Certificate message, and that
   certificate can represent a single DNS domain name. The client SHOULD
   include the "source domain" in the SNI extension and SHOULD NOT
   include the “derived domain”.

Notes:

There is nothing wrong with the text, however its missing some clarifying text.

When a client discovers a service using SRV, when it is doing TLS it should include the "source domain" in the SNI extension and SHOULD NOT include the “derived domain” in SNI. Now, this is obviously the correct thing to do. However, it doesnt explicitly state this anywhere in the RFC, or in RFC6066.

Errata ID: 5673
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Michael James
Date Reported: 2019-03-25

Throughout the document, when it says:

   If the certificate will be used for only a single type of application
   service, then the service provider is encouraged to request a
   certificate that includes a DNS-ID and, if appropriate for the
   application service type, an SRV-ID or URI-ID that limits the
   deployment scope of the certificate to only the defined application
   service type.

It should say:

   If the certificate will be used for only a single type of application
   service, the service provider is encouraged to request a
   certificate that includes a DNS-ID and, if appropriate for the
   application service type, an SRV-ID or URI-ID that limits the
   deployment scope of the certificate to only the defined application
   service type.

Notes:

All the sentences in the RFC (not just the one above) are written as pseudo code using IF...THEN. Normative English sentence structure the IF is a Conjunction for a Subordinating Clause. The THEN after the comma should be dropped to start the subject or main clause of the sentence.

Status: Held for Document Update (1)

RFC 6125, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", March 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3090
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Jeff Hodges
Date Reported: 2012-01-13
Held for Document Update by: Peter Saint-Andre
Date Held: 2012-02-27

Section 6.4.3 says:

6.4.3. Checking of Wildcard Certificates

   A client employing this specification's rules MAY match the reference
   identifier against a presented identifier whose DNS domain name
   portion contains the wildcard character '*' as part or all of a label
   (following the description of labels and domain names in
   [DNS-CONCEPTS]).

   For information regarding the security characteristics of wildcard
   certificates, see Section 7.2.

   If a client matches the reference identifier against a presented
   identifier whose DNS domain name portion contains the wildcard
   character '*', the following rules apply:

   1.  The client SHOULD NOT attempt to match a presented identifier in
       which the wildcard character comprises a label other than the
       left-most label (e.g., do not match bar.*.example.net).

   2.  If the wildcard character is the only character of the left-most
       label in the presented identifier, the client SHOULD NOT compare
       against anything but the left-most label of the reference
       identifier (e.g., *.example.com would match foo.example.com but
       not bar.foo.example.com or example.com).

   3.  The client MAY match a presented identifier in which the wildcard
       character is not the only character of the label (e.g.,
       baz*.example.net and *baz.example.net and b*z.example.net would
       be taken to match baz1.example.net and foobaz.example.net and
       buzz.example.net, respectively).  However, the client SHOULD NOT
       attempt to match a presented identifier where the wildcard
       character is embedded within an A-label or U-label [IDNA-DEFS] of
       an internationalized domain name [IDNA-PROTO].

It should say:

[ no firm test suggestions just as yet, please see below ]

Notes:

RFC6125 bug: Checking of Wildcard Certs lacks spec of how many labels in presented identifier

section 6.4.3 does not specify how many labels must be in a wildcarded presented identifier. I.e., it leaves open the possibility that the following presented identifiers could be matched against actual domain names..

*
*.
*.com i.e. *.<fill in TLD here> e.g.: *.uk or *.co.uk
*U i.e. *<fill in portion of TLD here> e.g.: will match AU, EDU, CU

etc. etc.


If actual TLS/SSL implementations (e.g. web browsers) were to make valid matches as shown above, then someone could ostensibly obtain a cert (c.f. diginotar) for one of them and then go and MITM large swaths of domain name space.

Note that the discussion of wildcards in Section 7.2 of security considerations identifies the public suffix issue in passing, but only as one of a set of issues why the spec discourages use of wildcard certs.

Note also that this issue begs the question of being able to determine what constitutes a so-called domain name "public suffix" (e.g. ".com", ".co.uk") -- we can't simply write into the spec "the wildcard must be in the left-most label position and there must be at least one? two? three? labels to the right of the wildcard's position".

Likely the approach will need to consist of a "SHOULD" declaration and some hand-waving about how "matching wildcards on presented identifiers with less than N (?) labels to the right of the wildcard has various increasing risks as N approaches zero, and that implementors should perhaps consider leveraging some of the available public suffix identification mechanisms, but that those are out of scope and have their own operational and security considerations."

PSA: This issue needs to be addressed, but doing so by means of an erratum is not the best way to go about having this conversation. Marking as "Hold For Document Update" to make sure we don't lose track of the issue. -- Peter Saint-Andre

Report New Errata