Re: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Nick Lamb via dev-security-policy]

On Thu, 24 Jan 2019 10:04:00 +0100
Kurt Roeckx via dev-security-policy
 wrote: 
> Will you fill something in in the commonName? I think what is
> expected in the commonName is what the user would type and expect to
> see, I don't think the commonName should contain
> xn--gau-7ka.siemens.de. If you have a commonName, I would expect that
> it contains gauß.siemens.de. And if you create a commonName then, you
> are required to check that it matches the xn--gau-7ka.siemens.de in
> the SAN.

I have two responses to this, first the practical one:

In Firefox (our most direct concern here on m.d.s.policy) of course CN
is entirely ignored for matching certificates in the Web PKI.

However many other clients exist, and we know most of them continue to
parse CN as you might have done twenty years ago trying to find some IP
address or DNS name in the human readable text. In some cases they
either don't understand SANs, or they prioritise matching CN over SANs.

This is a bad idea (if you are reading this and have responsibility for
the name matching algorithm in either a client or library I implore you
to go look at this again) but it's out there today and isn't going
away in the immediate future.

Concrete example: Until relatively recently Python's SSL/TLS
implementation, including in the very popular "Requests" library, would
match a Unicode hostname string against CN or SANs, even though that's
not correct behaviour. When a user asks to connect to 瞺瞹砡.example
the Python code correctly determines that it needs the DNS name
xn--b6yb42a.example to find the IP address but it still expects the
certificate to match 瞺瞹砡.example not xn--b6yb42a.example. This is of
course impossible for SANs by definition, and that impossibility was
helpful in persuading developers that their understanding of what
needed to happen here couldn't be correct.

I (as a relying party) would prefer that failure modes that fall out of
this sort of error aren't fatal to security. CAs that write SANs as
IA5-Strings with A-labels into CN fail safely here, whereas those which
try to conjure U-labels for a Unicode String risk tricking some of this
bad parser code into accepting a certificate for one name as valid for
a similar but different name or blowing up the parser itself (I haven't
seen examples where UCS-2 string data ends up written to a NUL-byte
terminated C string but I would not be surprised if it happens)

For compatibility reasons omitting CN altogether is not usually a good
plan, so to me that leaves writing the A-labels as the best option. I
believe Let's Encrypt currently has experiments ongoing as to how to
opt out of writing CN, but there's no intent to actually stop doing it
by default.

Second, a philosophical response:

The purpose of the Subject DN is to identify the Subject to a Relying
Party and we want it to be clear exactly which Subject we're
identifying. It is difficult, and maybe impossible, for a Certificate
Authority to specify how the user's input will be handled or how
exactly a name will be displayed in every possible user agent software.
On the other hand, the DNS A-labels, though unfamiliar to a human and
unwieldy to think about, have the advantage that they're definitely
identifying the specific thing we validated, not anything with a
different but similar name.

The reason it's hard for the CA to reason about Unicode names is that
not only do you have all of IDNA-2003, IDNA-2008, TR#46 but also
browsers have lots of counter measures (and the exact counter measures
deployed in famous brand browsers have changed over time) for the
problem of confusable DNS names. A browser may choose to write an IDN
in Punycode to avoid confusing users into believing the IDN is actually
some distinct name that merely looks similar.


My preferred outcome here would be for CAs to just voluntarily
choose not to write U-labels into CN AND for user agents to stop trying
to parse CN instead of just handling SANs. I think that's easier and
safer for basically everybody. But I don't feel strongly enough about
it that I feel we want "Incident Reports" for every scenario where this
didn't happen.

I do feel strongly enough about it that if a incident does happen and
the proximate cause was "We write U-labels into CN and that tripped a
bug" there's a good chance I will do the Nelson Muntz laugh and no
chance I'll have sympathy for the CA this happened to.

Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Wayne Thayer via dev-security-policy]

On Thu, Jan 24, 2019 at 8:17 AM Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> I agree with Rufus.  There are really two issues here:
>
> 1) The original reports to the CAs claimed an issue because RFC 5280
> references the original IDNA RFCs (now known as IDNA2003).
>
> RFC 5280 says "Rules for encoding internationalized domain names are
> specified in Section 7.2  >."
> Section 7.2 says: "one choice in GeneralName is the dNSName field, which is
> defined as type IA5String. IA5String is limited to the set of ASCII
> characters.  To accommodate internationalized domain names in the current
> structure, conforming implementations MUST convert internationalized domain
> names to the ASCII Compatible Encoding (ACE) format as specified in Section
> 4 of RFC 3490 before storage in the dNSName field."
>
> This makes it clear it is only discussing a case where a domain name is
> processed that does not meet the IA5String semantics.  Therefore both "
> xn--foo-bar-ghost.example.com" or "zq--special.example.com" are both
> acceptable in certificates as these do not need encoding and are valid
> preferred name syntax.
>
> Thank you for weighing in on this Peter. I think your (and Rufus')
interpretation of section 7.2 is a stretch, but I can admit that it isn't
clear if the intent is to require conformance to RFC 3490 if the string
does not require conversion. Given the ambiguity, I am now leaning toward
treating these misissuance reports as invalid.

2) How should CAs handle this going forward?
>
> RFC 8399, dated May 2018, explicitly updates RFC 5280.  It says "Conforming
> CAs SHOULD ensure that IDNs are valid.  This can be done by validating all
> code points according to IDNA2008 [RFC5892]."  Note that this is only a
> "SHOULD".  The CA/Browser Forum ballot 202 attempted to make this stricter,
> requiring that CAs not issue for names that contain Reserved LDH labels
> unless they start with the ACE prefix and the remainder is valid Punycode.
> However this ballot failed.
>
> This leaves us at the point that CAs "SHOULD" ensure IDNs are valid, but
> they may issue for names with any LDH label that passes the validation of
> control required by the BRs.
>
> Maybe Mozilla should add something about acceptable LDH labels to the CA
> policy?
>
> It appears that you proposed [1] an acceptable solution to the concerns
raised with this part of ballot 202 [2], so before creating a
Mozilla-specific policy I'd like to take another crack at solving it in the
BRs.

[1] https://cabforum.org/pipermail/public/2017-July/011774.html
[2]
https://cabforum.org/2017/07/26/ballot-202-underscore-wildcard-characters/

> Thanks,
> Peter
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Peter Bowen via dev-security-policy]

On Thu, Jan 24, 2019 at 4:17 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello
>
> > -Ursprüngliche Nachricht-
> > Von: Hanno Böck 
> > Gesendet: Donnerstag, 24. Januar 2019 12:36
> >
> > On Thu, 24 Jan 2019 11:14:11 + Buschart, Rufus wrote:
> >
> > > You are right, of course there are mandatory RFC to take into account.
> > > But there is - to my knowledge - no RFC that says, you MUST NOT issue
> > > a certificate to a domain that could be interpreted as an
> > > IDNA2008 punycode.
> >
> > https://tools.ietf.org/html/rfc5891
> >
> > 4.2.3.1.  Hyphen Restrictions
> >
> >The Unicode string MUST NOT contain "--" (two consecutive hyphens) in
> >the third and fourth character positions and MUST NOT start or end
> >with a "-" (hyphen).
> >
> > This means you can't have a valid host name that is just
> xn--[something]. You can only have it if it is also a valid IDN name.
> >
> I don't read it like this. This chapter describes the "Unicode string"
> which is the U-label before conversion. The hostname is the A-label after
> conversion and in the certificate you find the hostname. The RFC 3490
> clearly addressed this issue:
>
>While all ACE labels begin with the ACE prefix, not all labels
>beginning with the ACE prefix are necessarily ACE labels.  Non-ACE
>labels that begin with the ACE prefix will confuse users and SHOULD
>NOT be allowed in DNS zones.
>
> But first of all this is only a SHOULD requirement and second it places
> the burden on the operator of the DNS zones.
>

I agree with Rufus.  There are really two issues here:

1) The original reports to the CAs claimed an issue because RFC 5280
references the original IDNA RFCs (now known as IDNA2003).

RFC 5280 says "Rules for encoding internationalized domain names are
specified in Section 7.2 ."
Section 7.2 says: "one choice in GeneralName is the dNSName field, which is
defined as type IA5String. IA5String is limited to the set of ASCII
characters.  To accommodate internationalized domain names in the current
structure, conforming implementations MUST convert internationalized domain
names to the ASCII Compatible Encoding (ACE) format as specified in Section
4 of RFC 3490 before storage in the dNSName field."

This makes it clear it is only discussing a case where a domain name is
processed that does not meet the IA5String semantics.  Therefore both "
xn--foo-bar-ghost.example.com" or "zq--special.example.com" are both
acceptable in certificates as these do not need encoding and are valid
preferred name syntax.

2) How should CAs handle this going forward?

RFC 8399, dated May 2018, explicitly updates RFC 5280.  It says "Conforming
CAs SHOULD ensure that IDNs are valid.  This can be done by validating all
code points according to IDNA2008 [RFC5892]."  Note that this is only a
"SHOULD".  The CA/Browser Forum ballot 202 attempted to make this stricter,
requiring that CAs not issue for names that contain Reserved LDH labels
unless they start with the ACE prefix and the remainder is valid Punycode.
However this ballot failed.

This leaves us at the point that CAs "SHOULD" ensure IDNs are valid, but
they may issue for names with any LDH label that passes the validation of
control required by the BRs.

Maybe Mozilla should add something about acceptable LDH labels to the CA
policy?

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Hanno Böck via dev-security-policy]

On Thu, 24 Jan 2019 11:14:11 +
"Buschart, Rufus via dev-security-policy"
 wrote:

> You are right, of course there are mandatory RFC to take into
> account. But there is - to my knowledge - no RFC that says, you MUST
> NOT issue a certificate to a domain that could be interpreted as an
> IDNA2008 punycode.

https://tools.ietf.org/html/rfc5891

4.2.3.1.  Hyphen Restrictions

   The Unicode string MUST NOT contain "--" (two consecutive hyphens) in
   the third and fourth character positions and MUST NOT start or end
   with a "-" (hyphen).

This means you can't have a valid host name that is just
xn--[something]. You can only have it if it is also a valid IDN name.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy