On Sun, Jul 16, 2017 at 11:10:35PM -0700, Roland Bracewell Shoemaker wrote:
> On 07/16/2017 10:14 PM, Ilari Liusvaara wrote:
> > On Sun, Jul 16, 2017 at 04:29:20PM -0700, Roland Bracewell Shoemaker wrote:
> 
> The most recent proposed language clarifies that any method which looks
> up a DNS name for an IP using the reverse mapping then applies a 3.2.2.4
> method is considered acceptable.

Oh, indeed the draft does it that way.

Also, multiple mailing lists and unlabeled versions makes following what
is the most recent quite confusing... Missed the later version that
dropped most of the methods.

> > Also, the relevant section for TLS-SNI in the "7 methods" says:
> > 
> > "[...] a Certificate on the IP Address [...]"
> > 
> > Whatever that actually means (I can come up with at least two different
> > interpretations, and both of these are probably wrong):
> > 
> > - The certificate has to certify the IP address.
> > - The connection has to ask for certificate on IP address, i.e., omit
> >   server_name.
> > 
> > ... Both of these interpretations are technically problematic. And
> > neither is compatible with what the I-D text says.
> > 
> 
> My understanding of this, admittedly confusing, language simply means
> the certificate presented by whatever server is running on the IP, not
> that the cert needs to be for the IP or served blindly.
> 
> This language is in fact basically a copy/paste of the 3.2.2.4.10
> language, for which tls-sni-02 was designed to be compatible with, that
> is used for DNS names where "Authorization Domain Name" has been
> replaced with "IP Address".

I searched the archives of Validation WG.

The initial drafts of what became ballot 169 contained a method based
on text by J.C. Jones. This text covers TLS-SNI (even if I consider the
method bit dubious).

However, that definition got changed before the text became ballot,
specifically adding the "on the Authorization Domain Name" part. I can
not locate proper discussion of this change. Some text impiles it was
from F2F meeting, but minutes of that meeting don't seem to discuss the
matter.

Apparenty third interpretation of that is: Look up the IP address and
send some crap there. However, this interpretation seems to cause
trouble with method 6 (HTTP), which has the same language, with quite
clear implications.

Yeah, this is messy.


(And this confusing text is not the only problem with method 10, e.g.,
the method doesn't have the needed protections around use of random
values, seemingly allowing blatantly insecure validation... This
isn't fixed even in draft for ballot 190).



-Ilari

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to