Re: Second Last Call: draft-saintandre-tls-server-id-check (...) to BCP

Hi SM,

apologies for latency in replying..

 >>You mean removing the parenthetical "(following the definition of
 >>"label" from [DNS])", yes?
 >>
 >>In reviewing RFC 1035 I see your concern, tho we'd like to reference
 >>a description of "label". I note that RFC 1034 [S3.1] seems to
 >>appropriately supply this, so I propose we keep the parenthetical
 >>but alter it to be..
 >>
 >>   (following the description of labels and domain names in [DNS-CONCEPTS])
 >
 > That's fine to me.

k

 >
 >>Yes, but that definition (and term) appears to be specific to
 >>underlying DNS internals, not to (pseudo) domain names as wielded
 >>(or "presented" (eg in certs)) in other protocols.
 >
 > This brings us to the question of the DNS specific usage of "domain
 > names" and when the term is used in an application context.
 >
 > For example, is the left-most part in "foo*.example.com" (
 > draft-saintandre-tls-server-id-check-12, Section 5.2) acceptable as a label?

No, "foo*" isn't a legit dns label per se. However, it's only used in
"presented" domain names in various contexts -- certs being one -- and intended
for matching within applications, not for actual dereferencing via the DNS.

 > I'll react to some comments from Cullen Jennings.
 >
 > At 23:17 15-12-10, Cullen Jennings wrote:
 >>So let me start with I think there is great information in here and
 >>I think it should be published as a standards track RFC however I do
 >>think there are some issues with the relation with this draft and
 >>the realities of what would help improve security in deployment of
 >>SIP, HTTP, IMAP, XMPP etc.
 >
 > The information in draft-saintandre-tls-server-id-check is
 > helpful.  It's been a mouthful to comment on the draft as it requires
 > the reading of several referenced documents first.  This in itself
 > gives us an idea of the breath this draft tries to cover.
 >
 >>process review. Next this draft contradicts the procedures in
 >>existing protocols and says that it does not apply to the existing
 >>protocols but that it would take precedence over any future updates
 >>of existing protocols that use TLS within the scope specified here. I
 >
 > That begs the question about whether this draft should be a BCP.  I
 > would feel more comfortable if such a document is carefully reviewed
 > by people from the different application groups it touches on as it
 > attempts to shape the future.  This is not to say that there hasn't
 > been enough discussion about the draft or that it did not get
 > adequate socialization.  If the authors are of the opinion that there
 > has been that breath of review, I am fine with that.

above is no longer an issue as the draft is now approved as a proposed std. thx 
for the input on the issue in any case.

 >
 >>In section 3.2, in the imap example, you are saying that if I
 >>configure my imap server to mail.example.com and it presents a
 >>certificate with a DNS-ID of example.com that this is OK. That does
 >>not sound OK to me but I don't know how IMAP works. In the SIP example, the
 >
 > Consider an email address of "user@...".  The IMAP service is
 > discovered by the MUA by doing a DNS SRV lookup on _imaps.example.com
 > ( draft-daboo-srv-email ) and the target is mail.example.net, i.e
 > that's where the IMAP server is running.  The certificate provides a
 > SRV-ID of "_imaps.example.com" and a DNS-ID of "example.com".

we've incorp'd such an example in the draft, thx.

 >
 > BTW, the reference to draft-ietf-tls-rfc4366-bis could be normative
 > for the reader to understand SNI and not rely on the workaround for
 > multiple identifiers.

we don't feel its approp at this time to make that a normative reference, for
at least the reasons given in the draft in S7.4.

thanks again for your review,

=JeffH