[Uta] Requesting adoption of draft-rsalz-use-san

[Salz, Rich]

I presented this at SECDISPATCH, which said “get thee to UTA”



The draft is short, five pages, and updates RFC 6125 as described below.  6125 
was AD sponsored.



The draft below addresses some feedback given during the SECDISPATCH session.



Name:  draft-rsalz-use-san

Revision:  01

Title:  Update to Verifying TLS Server Identities with 
X.509 Certificates

Document date:   2021-03-13

Group:  Individual Submission

Pages:   5

URL: https://www.ietf.org/archive/id/draft-rsalz-use-san-01.txt

Status: https:/datatracker.ietf.org/doc/draft-rsalz-use-san/

Html:   https://www.ietf.org/archive/id/draft-rsalz-use-san-01.html

Htmlized:https://tools.ietf.org/html/draft-rsalz-use-san-01

Diff: https://www.ietf.org/rfcdiff?url2=draft-rsalz-use-san-01



Abstract:

   In the decade since [RFC6125] was published, the

   subjectAlternativeName extension (SAN), as defined in [RFC5280] has

   become ubiquitous.  This document updates [RFC6125] to specify that

   the fall-back techniques of using the commonName attribute to

   identify the service must not be used.  This document also places

   some limitations on the use of wildcards in SAN fields.



   The original context of [RFC6125], using X.509 certificates for

   server identity with Transport Layer Security (TLS), is not changed.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Adoption of draft-rsalz-use-san

[Salz, Rich]

> I think it would be much better to rewrite RFC 6125 with all the patches 
> applied, and then have that new document obsolete RFC 6125 instead of 
> updating it.

I took another look at 6125 and I am happy to put up a draft if the WG prefers 
that approach.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Adoption of draft-rsalz-use-san

[Salz, Rich]

>I’m quite certain this is NOT what Rich had in mind when he was writing 
> the document, and thus my suggestions.

There are more things in heaven and earth, Horatio, than are covered by your 
draft :)

Happy to add some wording if anyone has suggestions.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Adoption of draft-rsalz-use-san

[Salz, Rich]

Your suggestions seem okay to me, and we can work on it once adopted.  Thanks!

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Adoption of draft-rsalz-use-san

[Salz, Rich]

BTW, recorded here: https://github.com/richsalz/draft-rsalz-use-san/issues/1

From: Rich Salz 
Date: Monday, March 15, 2021 at 1:29 PM
To: Eliot Lear 
Cc: "uta@ietf.org" 
Subject: Re: [Uta] Adoption of draft-rsalz-use-san

Your suggestions seem okay to me, and we can work on it once adopted.  Thanks!

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Adoption of draft-rsalz-use-san

[Salz, Rich]

  *   It actually looks pretty good to me. The only thing I disagree with is 
"Severs either MUST NOT issue a CN-ID, or MUST use a form for the Common Name 
RDN that cannot be mistaken for an identifier" and similar language. It would 
be better to let people put whatever they want in the CN field of the subject 
whether or not it looks like a domain name. As long as conformant clients stop 
using the CN as a dNSName/iPAddress SAN alternative, then it doesn't matter 
what's in the CN. Probably some users will need to duplicate what's in the SAN 
in the subject CN for backward compatibility with nonconformant verifiers.

That’s a good point.  If the doc focuses purely on client behavior then that 
makes it easier for legacy, such as Elliot’s vehicle issue, and also makes it 
more clear about the wildcards.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Adoption of draft-rsalz-use-san

[Salz, Rich]

  *   The draft is adopted. Rich, can you please re-issue the draft with 
draft-ietf-uta-* name.

Posted, waiting confirmation from the chairs.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] How should we change draft-ietf-use-san?

[Salz, Rich]

I don’t know of a good way to address the concern raised by Eliot [1]. I don't 
want to make the requirements weaker. I would really like to hear from others. 

[1] https://mailarchive.ietf.org/arch/msg/uta/ayfVzc_j0kK7wY0_cW8OR9r81LE/

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] How should we change draft-ietf-use-san?

[Salz, Rich]

  *   I would very much like to stick to the original idea I proposed back 
before the initial draft: Let's just rewrite RFC 6125 to remove the concept of 
CN-ID, and call it a day. Don't put any requirements on producers of 
certificates. They can put whatever they want into the Common Name field and it 
will be ignored by conformant (to the new spec) validators.

I also think we should have the wildcard limitations that are in the 
draft-use-san.

The more I think about it, the more I am in favor of this. As I said back then, 
I’m willing to do it.

Anyone else have a preference between this and Eliot’s?

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] How should we change draft-ietf-use-san?

[Salz, Rich]

I am of mixed-mind about Eliot’s suggestions.  The phrase that keeps  coming 
back is “we’re not the protocol police.”

If an application wants to stay on its own specifications, and not follow the 
use-san document, it almost seems like it should just do that, and not clutter 
up use-san with escape hatches.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Some draft-ietf-uta-use-san nits

[Salz, Rich]

Victor suggests replacing section 3.3 as follows:
OLD:
   When constructing a list of reference identifiers, the client MUST
   NOT include any CN-ID present in the certificate. ...
NEW:
   When constructing a list of presented DNS identifiers, the client 
MUST
   use only DNS-ID SANs and MUST NOT include any CN-ID present in the
   certificate. ...

This seems okay to me, but I have a question about the ellipsis.  Are you 
suggesting that the "This means section 6.4.4..." sentence should be kept?

Also, on the definition of CN-ID:

>I think the original definition is better, and should just be retained
by reference, or repeated verbatim.

There draft says:
   The terminology from [RFC6125] is used here.  Specifically, the
   following terms and brief definition (as a reminder):
 
So I think there's a reference. I do not want to repeat the formal definition 
from 6125, it's a mouthful.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] How should we change draft-ietf-use-san?

[Salz, Rich]

I am beginning to think that doing a complete re-issue of 6125 will be better, 
because trying to fit the “patch” described below seems awkward.  On the other 
hand, if anyone has suggestions on how to do that, please post or email or make 
a PR at https://github.com/richsalz/draft-rsalz-use-san

From: Eliot Lear 
Date: Thursday, April 22, 2021 at 1:03 PM
To: Brian Smith 
Cc: Rich Salz , Jim Fenton , 
"uta@ietf.org" , 
Subject: Re: [Uta] How should we change draft-ietf-use-san?

Thanks, Brian.  I appreciate your patience.  The below totally works for me.


Eliot


On 22 Apr 2021, at 18:58, Brian Smith 
mailto:br...@briansmith.org>> wrote:

Eliot Lear mailto:l...@cisco.com>> wrote:
Actually, according to 802.1AR-2009, the subject MUST contain requires a DN 
with serial number, and it may contain a SAN (e.g., don’t count on it).  That’s 
the major concern.  To me, the rest is really negotiable.

OK, great. I don't think what Rich or what I'm proposing is in conflict with 
that at all.

The idea here is to tell certificate verifiers (relying parties):
* If you're looking for a DNS name in a certificate, only look in the 
subjectAltName, Don't look in the Subject Common Name.
* If you're looking for an IP address in a certificate, only look in the 
subjectAltName,  Don't look in the Subject Common Name.

That's it.

In the case of  802.1AR-2009, the verifier is to look for a distinguished name 
(either the Subject or a directoryName subjectAltName), not a DNS name or an IP 
address, so the proposed guidance wouldn't apply.

Note that RFC 6125 punted in IP addresses because they weren't commonly used in 
certificates in the working groups' judgement at the time, but now I think it 
is clear that an update to RFC 6125 should address IP addresses too.

Cheers,
Brian

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Salz, Rich]

>In summary, I don't see anything in use-san that will affect BRSKI.

That is great to hear, thanks for the careful analysis.

>Some nits:

All look like good things to do, I'll make a PR soonish.

What do you think of just rewriting this to completely replace 6125, rather 
than trying to be a "diff RFC"?

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Salz, Rich]

>There are a VAST number of devices that run off of iDevIDs: they never 
> transition off of them.  I’m not a fan, but that’s what they do.

Okay, so this draft doesn't apply to them.  There doesn't seem to be a problem 
with, say, not using TLS 1.3 in cases, or not using ECDH in some cases, so why 
is this draft different from those situation?  

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Salz, Rich]

>As I wrote, I think we’re past it, because this is about domain/IP address 
> validation and not client cert validation.  Correct?

Ah, right.  Thanks.  Too many balls in the air :)

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Salz, Rich]

Francesca do you have any guidance?  No rush, I have a month to publish another 
draft :)

From: Spencer IETF 
Date: Saturday, May 15, 2021 at 6:50 PM
To: Michael Richardson 
Cc: Rich Salz , "uta@ietf.org" , 
"an...@ietf.org" , "iot...@ietf.org" 
Subject: Re: [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

For what it's worth,

On Fri, May 14, 2021 at 1:52 PM Michael Richardson 
mailto:mcr%2bi...@sandelman.ca>> wrote:

Salz, Rich mailto:rs...@akamai.com>> wrote:
> That is great to hear, thanks for the careful analysis.

>> Some nits:

> All look like good things to do, I'll make a PR soonish.

> What do you think of just rewriting this to completely replace 6125,
> rather than trying to be a "diff RFC"?

If you mean, rfc6125bis, then it seems like it would risk opening wounds.
But, wholesale, "replace section X with "  might be useful.

I'd absolutely run this past the responsible AD. The IESG's view of patch RFCs 
versus diff RFCs varies over time, and I discovered late in my third term that 
the IESG didn't have a common understanding of what we should do in this case - 
and embarrassingly, I was in the rough.

Datatracker references on request, or you can trust me on this one ...

Best,

Spencer
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Salz, Rich]

  *   I believe the “obsoleting” path is a better choice here. In general, the 
“Updates” field can be interpreted in different ways, while “Obsoletes” is 
straightforward. In addition, 6125 does not have other documents updating it, 
so that information would not be lost by obsoleting it. Just be mindful of the 
risk of re-discussing old points not in scope of the current I-D, as Michael 
says.

So a full replacement.  Apply the current draft as a patch and post the result 
as the new version. :)  Ok.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Salz, Rich]

  *   there are few errata for RFC 6125 with different status (mostly Reported, 
but at least one - Held for Document Update) - RFC Errata Report » RFC Editor 
(rfc-editor.org)
  *   I also think that authors of original RFC should be contacted and asked 
whether they want to co-author bis document (and one of errata was reported by 
them).

That makes sense, I will do that.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] High level comments on draft-ietf-uta-use-san

[Salz, Rich]

  *   Some sections mention "server" while other sections does not state 
anything, therefor applying to both client and server. I think the draft needs 
to be very clear on this point.


  *   I saw that there was a discussion on client certs and that some client 
certs are built with CN and cannot be easily changed. Other uses of RFC 6125 
like the Service Based Architecture in 3GPP 5G makes little or no difference 
between server and client when it comes to certificates.

Thanks for reading it!  The current plan is to produce a stand-alone 6125bis, 
rather than the current diff/patch document. I’ll try to make sure these issues 
are cleared up.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Salz, Rich]

  *   IMO it's fine to contact the authors of an original RFC and point out 
that an update is needed.   But it's really presumptuous and rude to appoint 
oneself a co-author of a bis document and suggest that the original authors 
should become co-authors.   IMO that should be a last resort option, for the 
cases where the original authors aren't willing to revise their document, not 
the first suggestion made.

I am not sure I understand you.  Are you saying that once an RFC is authored, 
any BIS work must first be offered to the original authors?  If so, what about 
when the WG has been shut (LAMPS instead of PKIX)? Or this case, where someone 
wrote a draft and the WG adopted it.  Should the WG then ask the new author to 
wait until they’ve heard from the original authors? In this case, was I 
mistaken to submit a draft without first contacting Jeff and Peter before doing 
anything?




___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Salz, Rich]

After Valery’s suggestion I wrote to Jeff and Peter on May 24. No reply yet, 
but it’s been a holiday weekend in the US.

This particular document was AD-sponsored, so perhaps Keith’s thoughts are more 
applicable. For WG docs, however, another aspect to consider is that the WG 
owns the doc, the Chairs can pick any authors they like, and so I think his 
point boils down to common courtesy. Which, to be clear, is important.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] draft-ietf-uta-rfc6125bis replacement status updated by Valery Smyslov

[Salz, Rich]

Following the recommendations of our AD and WG chairs, I uploaded a new version 
of "use-san" to be a complete replacement of RFC6125. Peter and Jeff have 
agreed to be co-authors. Carsten graciously used tooling to convert the RFC 
Published XML to markdown. There is a GitHub repo for the document at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis  Right now it does NOT 
have the content from the draft, the first commits were about cleaning up the 
markdown.

First up is a pull request to make the wildcard changes.

On 6/29/21, 12:20 PM, "DraftTracker Mail System"  
wrote:


Please DO NOT reply to this email.

I-D: 
Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/

This document now replaces draft-ietf-uta-use-san instead of None



___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] draft-ietf-uta-rfc6125bis replacement status updated by Valery Smyslov

[Salz, Rich]

>   Following the recommendations of our AD and WG chairs, I uploaded a new 
> version of "use-san" to be a complete replacement of RFC6125. Peter and Jeff 
> have agreed to be co-authors. Carsten graciously used tooling to convert the 
> RFC Published XML to markdown. There is a GitHub repo for the document at 
> https://github.com/richsalz/draft-ietf-uta-rfc6125bis  Right now it does NOT 
> have the content from the draft, the first commits were about cleaning up the 
> markdown.

The pull request that brings forward the proposed wildcard changes can be found 
at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/1

The main change is that "*" can only appear in the left-most DNS label, and 
must be the first or only character in the label. Because of this 
simplification, much cautionary wording can be removed. Also, client support 
for "*" is now a MUST.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] draft-ietf-uta-rfc6125bis replacement status updated by Valery Smyslov

[Salz, Rich]

> Following the recommendations of our AD and WG chairs, I uploaded a new 
> version of "use-san" to be a complete replacement of RFC6125. Peter and Jeff 
> have agreed to be co-authors. Carsten graciously used tooling to convert the 
> RFC Published XML to markdown. There is a GitHub repo for the document at 
> https://github.com/richsalz/draft-ietf-uta-rfc6125bis  Right now it does NOT 
> have the content from the draft, the first commits were about cleaning up the 
> markdown.

The pull request that brings forward the proposed "don't use the CN at all" 
changes can be found at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/2

The main change is that all references to CN-ID which is the Common Name RDN " 
where the value matches the overall form of a domain name (informally, 
dot-separated letter-digit-hyphen labels)" have been removed. A couple of 
sentences about why it should not be used were added, but the bulk of the 
change is 200 deleted lines.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] Wildcards

[Salz, Rich]

A discussion started on the GitHub repo 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis about what is allowed for 
the wildcard character, such as in DNS entries in subjectAltName.  I am about 
to publish a new draft which takes the old adopted “diff” version and does a 
full version of 6125. The current draft says that a wildcard may be the first, 
or only, character in the left-most DNS name.

Brian Smith and Ryan Sleevi started a discussion on the PR 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/1#discussion_r663206174
 recommending that the doc should be the *only* character.  For example, 
*.apps.example.com is okay, but *apps.example.com is not.

I’d like to know what the WG thinks.  As we’re not really using GitHub for 
discussion, please comment on this list.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Wildcards

[Salz, Rich]

In anticipation of consensus around "only * as the left-most label," I created 
a PR; https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/9


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Wildcards

[Salz, Rich]

I agree with the reasoning, but I think you have to deprecate before removal 
and therefore not in this draft.

We could update the security concerns and say MAY NOT about issuance perhaps. 
The text already says clients MAY use them.

They're still allowed in the WebPKI, and I am unsure of non-web uses.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Wildcards

[Salz, Rich]

I am adding the following commit to 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/9 which I will merge 
if/when we have consensus.
Let me know if this is not ok.

MAC ~/git/draft-ietf-uta-rfc6125bis$ g l1
commit d4dcbd397e1342c634f3ab19eb4bc52b4b7ef5e8 (HEAD -> simpler-wildcard)
Author: Rich Salz 
Date:   Sat Jul 10 17:39:57 2021 -0400

Clarify wildcard/DNS-wildcard differences

Per the email discussion. Thanks Tony, Ryan, and Jim.
---
 draft-ietf-uta-rfc6125bis.md | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/draft-ietf-uta-rfc6125bis.md b/draft-ietf-uta-rfc6125bis.md
index a1aa0ee..71f305d 100644
--- a/draft-ietf-uta-rfc6125bis.md
+++ b/draft-ietf-uta-rfc6125bis.md
@@ -38,6 +38,7 @@ author:
 normative:
   DNS-CONCEPTS: RFC1034
   DNS-SRV: RFC2782
+  DNS-WILDCARDS: RFC4592
   IDNA-DEFS: RFC5890
   IDNA-PROTO: RFC5891
   LDAP-DN: RFC4514
@@ -1081,7 +1082,7 @@ The rules differ depending on whether the domain to be 
checked is a
 defined under {{names-dns}}).
 Furthermore, to meet the needs of clients that support presented
 identifiers containing the wildcard character `*`, we define a
-supplemental rule for so-called "wildcard certificates".
+supplemental rule for such "wildcard certificates".
 
 ### Checking of Traditional Domain Names {#verify-domain-trad}
 
@@ -1125,6 +1126,12 @@ provided these requirements are met:
 3. The wildcard character is not embedded in an A-label or U-label
{{IDNA-DEFS}} of an internationalized domain name {{IDNA-PROTO}}.
 
+A wildcard in a presented identifier can only match exactly one label in
+a reference identifier. Note that this is not the same as DNS wildcard
+matching, where the `*` label always matches at least one whole
+label and sometimes more. See {{DNS-CONCEPTS, Section 4.3.3}}
+and {{DNS-WILDCARDS}}.
+
 For information regarding the security characteristics of wildcard 
certificates,
 see {{security-wildcards}}.
 
@@ -1246,8 +1253,9 @@ relevant information provided by the user or associated 
by the client).
 
 Wildcard certificates, those that have an identifier with
`*` as the left-most DNS label,
-automatically vouch for any and all host names
-within their domain. This can be convenient for administrators but
+automatically vouch for any single-label host names
+within their domain, but not multiple levels.
+This can be convenient for administrators but
 also poses the risk of vouching for rogue or buggy hosts. See for
 example {{Defeating-SSL}} (beginning at slide 91) and {{HTTPSbytes}}
 (slides 38-40).

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Wildcards

[Salz, Rich]

> +A wildcard in a presented identifier can only match exactly one label 
> in
> +a reference identifier. Note that this is not the same as DNS wildcard
> +matching, where the `*` label always matches at least one whole
> +label and sometimes more. See {{DNS-CONCEPTS, Section 4.3.3}}
> +and {{DNS-WILDCARDS}}.

>The language in RFC 2818 is narrower than this.  It allows '*' to match 
> only the first label.

I don't think that makes the above text incorrect, since this draft says "only 
the first label"

>(Note that `*` will be rendered in text as "*" and HTML as a bare * in 
> fixed-width font, which might not be visible

I changed to use explicit quotes "\*"  Thanks.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Wildcards

[Salz, Rich]

>Support for wildcards in RFC 6125 is application-protocol specific, see
Appedix B.

Well, I want to make 6125bis be a Standard, not a best practices, so Appendix B 
is gone from my draft :)

But yes, I still want wildcards to be a MAY.  Perhaps a SHOULD.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Wildcards

[Salz, Rich]

  *   that further validation happens outside (before, after, or in parallel 
to) RFC 6125 processing.

It seems like it would be worthwhile for us to mention that in the beginning.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Wildcards

[Salz, Rich]

I think the 6125 was explicit about what it covered, and I hope the new version 
will be more explicit: how to validate server “names” when using PKIX certs and 
TLS.

Everything else is out of scope. As Viktor said, it’s often local policy.  What 
RFC describes Chrome’s behavior?  And why should there be one?

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Wildcards

[Salz, Rich]

>> I don't think that makes the above text incorrect, since this draft 
>> says "only the first label"

>Sort of.  The text I quoted does not.  You could say "can only match the 
> leftmost label in ...".

Assuming we have consensus, the PR on this says that the wildcard character can 
only be the first label, so I think it's set.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] rfc7525bis and CNSA

[Salz, Rich]

> We are wondering if the WG
thinks it makes sense to adopt some of these recommendations and
informatively reference draft-cooley-cnsa-dtls-tls-profile from rfc7525bis.

I strongly support this.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] Removing "the directory" text

[Salz, Rich]

At the meeting yesterday, I said I think we should remove text about the X.500 
directory and some people, quite reasonably, wanted to see the text.  A diff is 
attached.  You can also find it at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/10  It removes 
references to X.500, X.501, X.509, and X.520 and about 80 other lines of text. 
I am, perhaps, too proud that the branch is named “rmdir” :)


rmdir.diff
Description: rmdir.diff
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] Planned 6125bis changes

[Salz, Rich]

I am planning on merging two pull requests next week, unless there is strong 
objection.  I mentioned these at the last IETF. There has been no mailing list 
traffic on them.

https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/10 Removes all 
mention of X.500 (The Directory) except to say “don’t use Subject RDN’s”

https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/11 Rewrites the 
“design checklist” so that Appendix A, this one, is no longer necessary. In my 
view, the changed text still needs editing in order to have more MUST SHOULD 
MAY language, but that can wait.

Also, these are just editorial and I will do them at the same time.

https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/13

https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/18 adds a “Changes 
since RFC 6125”

And then I’ll probably post a new version.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Planned 6125bis changes

[Salz, Rich]

I merged the PR’s and draft-02 is now available at 
https://www.ietf.org/id/draft-ietf-uta-rfc6125bis-02.html, etc.

From: Rich Salz 
Date: Monday, August 30, 2021 at 12:57 PM
To: "uta@ietf.org" 
Subject: Planned 6125bis changes

I am planning on merging two pull requests next week, unless there is strong 
objection.  I mentioned these at the last IETF. There has been no mailing list 
traffic on them.

https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/10 Removes all 
mention of X.500 (The Directory) except to say “don’t use Subject RDN’s”

https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/11 Rewrites the 
“design checklist” so that Appendix A, this one, is no longer necessary. In my 
view, the changed text still needs editing in order to have more MUST SHOULD 
MAY language, but that can wait.

Also, these are just editorial and I will do them at the same time.

https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/13

https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/18 adds a “Changes 
since RFC 6125”

And then I’ll probably post a new version.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] Pinning

[Salz, Rich]

I would like to remove the discussion of pinning from 5126bis for the following 
reason:


  *   It’s an escape hatch, saying “do all these things but if you don’t get a 
match, you can pin.”
  *   The current wording allows its use, anyway.
  *   Pinning is bad.

A proposed change is in 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/19

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Pinning

[Salz, Rich]

>Perhaps the text can be made more concise, but I don't think full
removal is warranted.  This is *not* the fragile key pinning from HPKP.

Right now the text has this.  Is more needed?

### Failure: No Match Found

If the client does not find a presented identifier matching any of the
reference identifiers then the client MUST
proceed as described as follows.

If the client is an automated application not directly controlled
by a human user, then it SHOULD terminate the communication attempt with
a bad certificate error and log the error appropriately.
An automated application
MAY provide a configuration setting that disables this behavior, but it
MUST enable the behavior by default.

If the client is an interactive client that is directly controlled by a human
user, then it SHOULD inform the user of the identity mismatch and automatically
terminate the communication attempt with a bad certificate error; this behavior
is preferable because it prevents users from inadvertently bypassing security
protections in hostile situations.

Some interactive clients give advanced users the option
of proceeding with acceptance despite the identity mismatch.
Although this behavior can be appropriate in certain specialized
circumstances, it needs to be handled with
extreme caution, for example by first encouraging even an advanced user to
terminate the communication attempt and, if the advanced user chooses to
proceed anyway, by forcing the user to view the entire certification path
before proceeding.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Pinning

[Salz, Rich]

This is most of what's needed.  Plus something along the lines of:

In some cases the user should be able to accept the certificate in
question as valid also for subsequent connections.  Such ad-hoc
"pinning" should typically not restrict future connections to just
the pinned certificate.

Local policy that statically enforces a given certificate for a
given peer is best made available only as prior configuration,
rather than a just-in-time override for a failed connection.

Feel free to word smith if largely acceptable, or clarify objections if
not...

Largely acceptable to me :)  I'll tweak a bit and add it to the pull request 
soon.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Pinning

[Salz, Rich]

>This is most of what's needed.  Plus something along the lines of:

I updated https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/19 to have 
something based on Viktor's suggestion. The main wording changes were about 
using MUST MAY SHOULD language in that whole section.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] High level comments on draft-ietf-uta-use-san

[Salz, Rich]

FYI, I created https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/21 
for this.

From: Brian Smith 
Date: Tuesday, June 1, 2021 at 6:34 PM
To: Rich Salz 
Cc: "john.matts...@ericsson.com" , "uta@ietf.org" 

Subject: Re: [Uta] High level comments on draft-ietf-uta-use-san

Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:


  *   Some sections mention "server" while other sections does not state 
anything, therefor applying to both client and server. I think the draft needs 
to be very clear on this point.


  *   I saw that there was a discussion on client certs and that some client 
certs are built with CN and cannot be easily changed. Other uses of RFC 6125 
like the Service Based Architecture in 3GPP 5G makes little or no difference 
between server and client when it comes to certificates.

Thanks for reading it!  The current plan is to produce a stand-alone 6125bis, 
rather than the current diff/patch document. I’ll try to make sure these issues 
are cleared up.

I think we should avoid mentioning roles like "client" or "server" except 
non-normatively to emphasize that the spec would apply to both roles. What 
matters is that the entity's identity is a DNS name.

Cheers,
Brian

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] High level comments on draft-ietf-uta-use-san

[Salz, Rich]

>RFC 6125 was written with TLS in mind (it's even mentioned in the
title), and in any given TLS interaction one entity is the client and
the other is the server. The use of these terms in RFC 6125 had nothing
to do with what are usually called "client certs" (e.g., a certificate
associated with a particular user's web browser when TLS is used in the
context of HTTP).

>That said, I agree that we can make things clearer.

I think that's realistically all we should do.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] 6125bis changes

[Salz, Rich]

I merged the pinning PR. After Viktor’s addition it seemed non-controversial. 
It’s now only discussed in the “failed to find an identifier” section as a 
fallback.

I have another PR, 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23 that does a lot 
of editing on the Introduction section.  In addition to just word-smithing, it 
also adds some text to address the following:

  *   Make more explicit that this is just *part* of what’s necessary to 
validate identity 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/22


  *   Point out that this can apply to peer-to-peer, i.e., “both sides” as 
well. https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/21


The diff is big and mostly boring so I am not going to post is to the list. I 
will mail it if anyone has problems or issues using the GitHub links.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] 6125bis changes

[Salz, Rich]

I have a PR that does a lot of editing of the “naming” section.  It is mostly 
editorial work, also an update for cross-protocol
Attacks.  It is at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/24 and is based on 
the existing PR to edit the “introduction” section.  As with that, the diff is 
big and mostly boring so I encourage people to look at the PR.  If you have 
problems or issues with looking at the GitHub content, get in touch and I will 
email you the diff.

I also have a PR that edits the “designing protocols” section at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/25. This is a mix of 
editorial, and also using more MUST MAY SHOULD language. It’s short, so here is 
the complete new text.

I would greatly appreciate comments on these, as well as 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23, which I 
mentioned last week.

+This section defines how protocol designers should reference this document,
+which MUST be a normative reference in their specification.  The technology
+MUST only use the identifiers defined in this document.  Its specification
+MAY choose to allow only one of them.
+
+If the technology does not use DNS SRV records to resolve the DNS domain
+names of application services then its specification MUST state that SRV-ID
+as defined in this document is not supported.  Note that many existing
+application technologies use DNS SRV records to resolve the DNS domain names
+of application services, but do not rely on representations of those records
+in PKIX certificates by means of SRV-IDs as defined in {{SRVNAME}}.
+
+If the technology does not use URI's to identify application services, then
+its specification MUST state that URI-ID as defined in this document is not
+supported.  Note that many existing application technologies use URIs to
+identify application services, but do not rely on representation of those
+URIs in PKIX certificates by means of URI-IDs.
+
+A technology MAY disallow the use of the wildcard character in DNS names. If
+it does so, then the specification MUST state that wildcard certificates as
+defined in this document are not supported.
 # Representing Server Identi
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] 6125bis: client and server

[Salz, Rich]

John Mattson had pointed out that the document uses client and server, when in 
fact if you use mutual auth or machine-to-machine, that’s not really correct.  
Peter st Andre explained that it’s the terms used in TLS. I just merged a PR 
that addresses some of this, but not all. John and others interested in this 
issue, should look at the new draft when published next week.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 6125bis changes

[Salz, Rich]

I have merged the first two big, boring, editorial PR’s and would like WG 
feedback on the quoted text below.  Thanks.

From: "Salz, Rich" 
Date: Wednesday, September 22, 2021 at 2:58 PM
To: "uta@ietf.org" 
Subject: [Uta] 6125bis changes

I have a PR that does a lot of editing of the “naming” section.  It is mostly 
editorial work, also an update for cross-protocol
Attacks.  It is at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/24<https://urldefense.com/v3/__https:/github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/24__;!!GjvTz_vk!Ebp3Qq-dElPSiy9T3jzr5vSIL8YWjrRUvcuoziiEZFNJ4K4baDcvocw8qxKz$>
 and is based on the existing PR to edit the “introduction” section.  As with 
that, the diff is big and mostly boring so I encourage people to look at the 
PR.  If you have problems or issues with looking at the GitHub content, get in 
touch and I will email you the diff.

I also have a PR that edits the “designing protocols” section at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/25<https://urldefense.com/v3/__https:/github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/25__;!!GjvTz_vk!Ebp3Qq-dElPSiy9T3jzr5vSIL8YWjrRUvcuoziiEZFNJ4K4baDcvoTi0isVB$>.
 This is a mix of editorial, and also using more MUST MAY SHOULD language. It’s 
short, so here is the complete new text.

I would greatly appreciate comments on these, as well as 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23<https://urldefense.com/v3/__https:/github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23__;!!GjvTz_vk!Ebp3Qq-dElPSiy9T3jzr5vSIL8YWjrRUvcuoziiEZFNJ4K4baDcvoRkj7me0$>,
 which I mentioned last week.

+This section defines how protocol designers should reference this document,
+which MUST be a normative reference in their specification.  The technology
+MUST only use the identifiers defined in this document.  Its specification
+MAY choose to allow only one of them.
+
+If the technology does not use DNS SRV records to resolve the DNS domain
+names of application services then its specification MUST state that SRV-ID
+as defined in this document is not supported.  Note that many existing
+application technologies use DNS SRV records to resolve the DNS domain names
+of application services, but do not rely on representations of those records
+in PKIX certificates by means of SRV-IDs as defined in {{SRVNAME}}.
+
+If the technology does not use URI's to identify application services, then
+its specification MUST state that URI-ID as defined in this document is not
+supported.  Note that many existing application technologies use URIs to
+identify application services, but do not rely on representation of those
+URIs in PKIX certificates by means of URI-IDs.
+
+A technology MAY disallow the use of the wildcard character in DNS names. If
+it does so, then the specification MUST state that wildcard certificates as
+defined in this document are not supported.

 # Representing Server Identi
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 6125bis: client and server

[Salz, Rich]

> I just merged a PR that addresses some of this, but not all. John and
> others interested in this issue, should look at the new draft when
> published next week.

I'll try to take a look.  Which PR number?

Thank you Viktor.  This pull request has the changes, 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23, and the text is 
here:
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23/files#diff-2c24bab3daea8d575b90f4179372ebc69ca9d57b807e5588ac05ba9bcfa94891R253


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] Viktor's feedback

[Salz, Rich]

Viktor made some comments on 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23 and here is my 
proposal to address them.


diff --git a/draft-ietf-uta-rfc6125bis.md b/draft-ietf-uta-rfc6125bis.md
index 28cc46f..8bb46f4 100644
--- a/draft-ietf-uta-rfc6125bis.md
+++ b/draft-ietf-uta-rfc6125bis.md
@@ -275,17 +275,19 @@ systems.
 TLS uses the words client and server, where the client is the entity
that initiates the connection.  In many cases, this models common practice,
-such as a browser connecting to a Web origin.  Sometimes, however, the two
-parties can be more properly considered as peers, and often the initiating
-client will also have a certificate that the server must verify, known as
-mutual authentication.  In that environment, the rules specified here SHOULD
-also be applied.  For the sake of clarity, however, we will continue to use
+such as a browser connecting to a Web origin.
+For the sake of clarity, and to follow the usage in {{TLS}} and related
+specifications, we will continue to use
to use the terms client and server in this document.
+Note that these are TLS-layer roles, and that the application protocol
+could support the TLS server making requests to the TLS client after the
+TLS handshake; these is no requirement that the roles at the application
+layer match the TLS-layer.
 At the time of this writing, other protocols such as {{QUIC}} and
Network Time Security (NTS, {{NTS}}) use TLS as a service to do the
initial establishment of cryptographic key material.
-Those services MUST also follow the rules specified here.
+Such services MUST also follow the rules specified here.
 ### Out of Scope {#out-of-scope}
@@ -299,7 +301,7 @@ The following topics are out of scope for this 
specification:
* Client or end-user identities.
   Certificates representing client identities other than that
-  described above can also be, such as rfc822Name, but is beyond the scope
+  described above, such as rfc822Name, are beyond the scope
   of this document.
 * Identifiers other than fully qualified DNS domain names.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] 6125bis -- security considerations

[Salz, Rich]

I am proposing the following for the security section.  Any comments?  In 
particular, what about the “multiple identifiers” at the last few lines?  
Should that go away now?  If so, that will have ripple effects.  This text is 
currently at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/29


# Security Considerations {#security}

## Wildcard Certificates {#security-wildcards}

Wildcard certificates, those that have an identifier with "\*" as the
left-most DNS label, automatically vouch for any single-label host names
within their domain, but not multiple levels of domains.  This can be
convenient for administrators but also poses the risk of vouching for rogue
or buggy hosts. See for example {{Defeating-SSL}} (beginning at slide 91) and
{{HTTPSbytes}} (slides 38-40).

Protection against a wildcard that identifies a public suffix
{{Public-Suffix}}, such as `*.co.uk` or `*.com`, is beyond the scope of this
document.

## Internationalized Domain Names {#security-idn}

Allowing internationalized domain names can lead to the inclusion of visually
similar, or confusable, characters in certificates.  For discussion, see for
example {{IDNA-DEFS}}.

## Multiple Identifiers {#security-multi}

A given application service might be addressed by multiple DNS domain names
for a variety of reasons, and a given deployment might service multiple
domains or protocols.  The client MUST use the TLS Server Name Identification
(SNI) extension as discussed in {{TLS, Section 4.4.2.2}}.  If multiple
protocols share the same port, the client MUST use the Application-Layer
Protocol Negotiation as described in {{ALPN}}.

To accommodate the workaround that was needed before the development
of the SNI extension, this specification allows multiple DNS-IDs,
SRV-IDs, or URI-IDs in a certificate.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 6125bis -- security considerations

[Salz, Rich]

Your suggestions make sense to me.  Let’s see if anyone disagrees.  Thanks for 
reading!  I agree about the PSL and spreading it around. Maybe just drop the 
reference?  But then, I understood what you wrote about crossing the beams, er 
administrative domains.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 6125bis -- security considerations

[Salz, Rich]

Thanks for your feedback, Ryan and Alexey.  I basically did what you suggested.

I share your concerns about the public suffix list.  Does the WG have any 
thoughts?  FYI, Ryan wrote this:


  *   I'm a little sad any time there is a new dependency on the public suffix 
list, even informative :) I realize the point is to say it's out of scope, and 
alternative language, such as "wildcard that spans multiple domain 
administration boundaries" is as clear as mud and reads like a mouthful of 
marbles. My main concern/consideration is that the whole "wildcards and PSL" is 
messy (all the more reason to keep it out of scope!), although I worry folks 
will read this and think "Oh, this is a hint to use the PSL, nudge and wink"

Alexey convinced me ALPN is out of scope, it’s more about “how to use TLS in 
applications” :) not this specific document.

I still would like comments on the last paragraph of the section:


  *   To accommodate the workaround that was needed before the development of 
the SNI extension, this specification allows multiple DNS-IDs, SRV-IDs, or 
URI-IDs in a certificate.

Should that go away now?  If so, that will have ripple effects.  Perhaps just 
add that this MAY be the equivalent of multiple names, could enable 
cross-protocol attacks, and should be avoided unless necessary?


The revised section is at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/29

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 6125bis -- security considerations

[Salz, Rich]

  *   What sort of ripple effects are you thinking?

Purely editorial within the document which talks about one or more 
DNS-ID/URI-ID in a couple of places.


  *   I agree that, in practice, the use of multiple names has been normalized 
beyond the "SNI workaround" (e.g. the discussions on cross-SNI resumption or 
the ORIGIN frame), so removing that text seems acceptable, but I suspect that 
we'd both be on the same page of wanting to say _something_ about the risks, 
such as cross-protocol attacks. And if we're going to discuss those, would it 
also be appropriate to discuss the concerns about accepting multiple different 
_types_ of identifiers within a message, and the intersection that can play 
with, for example, nameConstraints.

Yes I think we are.


  *   That is, I've seen far too many implementations that will accept (DNS-ID 
|| URI-ID) within a TLS endpoint, but will happily ignore that while a DNS-ID 
will be constrained by DNS nameConstraints, those same nameConstraints won't 
constrain the URI-ID unless URI nameConstraints are included, and notably... 
they aren't required to be included in popular PKIs like the Web PKI.

I didn’t even realize URI nameConstraints were possible.


  *   Happy to suggest text if folks think it's worth tackling during this 
revision, although it seems a separate-but-related attack to the cross-protocol 
attack.

Please do!

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 6125bis -- security considerations

[Salz, Rich]

Thanks for the contribution, Ryan.

I already merged your two smaller changes around SNI and ALPN.  I hope the WG 
will comment on the larger text you provided, below.
Ryan’s mail.

I'm specifically proposing splitting up "Multiple Identifiers" into two 
discussions - "Multiple Presented Identifiers" (multiple names in certs, and 
concerns for server operators) and "Multiple Reference Identifiers" (multiple 
acceptable names to match, and concerns for client implementations)

The proposed new text is reproduced below (improperly wrapped), again, for the 
GitHub averse :)

This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a
certificate, which allows for a single application service to use the
same certificate for multiple identifiers. This enables a single certificate
to be used across multiple hostnames, such as when a client does not
support the TLS SNI extension, or across multiple protocols, such as
SMTP and HTTP, on a single hostname. The use of a single certificate
and public/private keypair in such environments MAY facilitate
cross-protocol attacks, particularly when used in differing TLS
configurations. See, for example, {{ALPACA}}, {{DROWN}}. Server
operators SHOULD take steps to mitigate the risk of cross-protocol
attacks, such as ensuring all TLS endpoints using a given certificate
support exactly the same TLS version(s) and ciphersuite(s), and
SHOULD make use of the TLS ALPN extension to ensure the correct
protocol is used.

## Multiple Reference Identifiers

This specification describes how a client may construct multiple
acceptable reference identifiers, and may match any of those reference
identifiers with the set of presented identifiers. {{PKIX, Section 4.2.1.10}}
describes a mechanism to allow CA certificates to be constrained in the
set of presented identifiers that they may include within server certificates.
However, these constraints only apply to the explicitly enumerated name
forms. For example, a CA that is only name constrained for DNS-IDs is not
constrained for SRV-IDs and URI-IDs, unless those name forms are also
explicitly included within the name constraints extension.

A client that constructs multiple reference identifiers of different types,
such as both DNS-ID and SRV-IDs, as described in
{#verify-reference-rules}, SHOULD take care to ensure that CAs issuing
such certificates are appropriately constrained. This MAY take the form of
local policy through agreement with the issuing CA, or MAY be enforced by
the client requiring that if one form of presented identifier is constrained,
such as a dNSName name constraint for DNS-IDs, then all other forms of
acceptable reference identities are also constrained, such as requiring a
uniformResourceIndicator name constraint for URI-IDs.

I understand this latter text may have some degree of controversy attached; one 
of the intended aspects of flexibility with nameConstraints was precisely that 
it allows new name forms to be introduced in the future, without requiring the 
reissuance of certificates. I've tried to balance that with the client 
behaviour, namely, that a client shouldn't construct a given reference 
identifier / allow a match for a given reference identifier unless it's 
constrained, _if_ it accepts other forms of constrained reference identifiers.

The canonical example here of the challenge is something like introducing 
support for SRV-IDs within browser clients, which would be a huge boon to 
reducing the risk of cross-protocol issues like ALPACA. However, clients cannot 
(safely) do this as long as there exist servers that are only constrained for 
dNSNames, without corresponding SRVName constraints. This tries to balance 
that, by suggesting the client should, when presented with such a constrained 
chain, only allow DNS-ID reference identifiers to match (because the indication 
that "some" constraint was intended). Reissuance of that intermediate, to also 
constrain SRVName, would provide the explicit signal to the client that it's 
acceptable (or not) to use SRV-ID reference identifiers.

This does not holistically integrate it (e.g. by adding a cross-reference to 
#verify-reference-rules to the security considerations), but is meant to see if 
there is objection/concern with this approach.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 6125bis -- multiple identifiers (was security considerations)

[Salz, Rich]

  *   It started off with this discussion, but clearly, it's a much broader 
change. It does try and reintroduce the ALPN conversation, although with a 
looser 2119 fit, and trying to explain the "why" of the SHOULD, in a way 
directly relevant to this specification, in a way that is hopefully acceptable 
to mitigating the concerns previously raised.


  *   I'm specifically proposing splitting up "Multiple Identifiers" into two 
discussions - "Multiple Presented Identifiers" (multiple names in certs, and 
concerns for server operators) and "Multiple Reference Identifiers" (multiple 
acceptable names to match, and concerns for client implementations)

I really like your proposal. I split it off into its own pull request, 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/33.  Again for this 
not comfortable with GitHub, here’s the new text, followed by Ryan’s comments 
on it.

This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a
certificate, which allows for a single application service to use the
same certificate for multiple identifiers. This enables a single certificate
to be used across multiple hostnames, such as when a client does not
support the TLS SNI extension, or across multiple protocols, such as
SMTP and HTTP, on a single hostname. The use of a single certificate
and public/private keypair in such environments MAY facilitate
cross-protocol attacks, particularly when used in differing TLS
configurations. See, for example, {{ALPACA}}, {{DROWN}}. Server
operators SHOULD take steps to mitigate the risk of cross-protocol
attacks, such as ensuring all TLS endpoints using a given certificate
support exactly the same TLS version(s) and ciphersuite(s), and
SHOULD make use of the TLS ALPN extension to ensure the correct
protocol is used.

## Multiple Reference Identifiers

This specification describes how a client may construct multiple
acceptable reference identifiers, and may match any of those reference
identifiers with the set of presented identifiers. {{PKIX, Section 4.2.1.10}}
describes a mechanism to allow CA certificates to be constrained in the
set of presented identifiers that they may include within server certificates.
However, these constraints only apply to the explicitly enumerated name
forms. For example, a CA that is only name constrained for DNS-IDs is not
constrained for SRV-IDs and URI-IDs, unless those name forms are also
explicitly included within the name constraints extension.

A client that constructs multiple reference identifiers of different types,
such as both DNS-ID and SRV-IDs, as described in
{#verify-reference-rules}, SHOULD take care to ensure that CAs issuing
such certificates are appropriately constrained. This MAY take the form of
local policy through agreement with the issuing CA, or MAY be enforced by
the client requiring that if one form of presented identifier is constrained,
such as a dNSName name constraint for DNS-IDs, then all other forms of
acceptable reference identities are also constrained, such as requiring a
uniformResourceIndicator name constraint for URI-IDs.


  *   I understand this latter text may have some degree of controversy 
attached; one of the intended aspects of flexibility with nameConstraints was 
precisely that it allows new name forms to be introduced in the future, without 
requiring the reissuance of certificates. I've tried to balance that with the 
client behaviour, namely, that a client shouldn't construct a given reference 
identifier / allow a match for a given reference identifier unless it's 
constrained, _if_ it accepts other forms of constrained reference identifiers.


  *   The canonical example here of the challenge is something like introducing 
support for SRV-IDs within browser clients, which would be a huge boon to 
reducing the risk of cross-protocol issues like ALPACA. However, clients cannot 
(safely) do this as long as there exist servers that are only constrained for 
dNSNames, without corresponding SRVName constraints. This tries to balance 
that, by suggesting the client should, when presented with such a constrained 
chain, only allow DNS-ID reference identifiers to match (because the indication 
that "some" constraint was intended). Reissuance of that intermediate, to also 
constrain SRVName, would provide the explicit signal to the client that it's 
acceptable (or not) to use SRV-ID reference identifiers.


  *   This does not holistically integrate it (e.g. by adding a cross-reference 
to #verify-reference-rules to the security considerations), but is meant to see 
if there is objection/concern with this approach.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] Editorial changes to 6125bis

[Salz, Rich]

I have a number of editorial changes I want to make to the draft.

Most of them are about avoiding redundant terms like “client” instead of 
“interactive or automated client” and CA, etc., instead of “certification 
authority”, etc.  The diffs are big (83 lines added and 95 lines removed, for a 
diff of 440 lines) so I won’t post it here. You can find it at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/34  If anyone has 
issues or problems with GitHub, let me know and I’ll email it to you.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Editorial changes to 6125bis

[Salz, Rich]

Thanks!  I agree I could have gone overboard in relying on the sentence “Some 
abbreviations are so well known that expansion is probably
Unnecessary” from https://www.rfc-editor.org/materials/abbrev.expansion.txt.  
So I think maybe wait for the editorial pass, but I’m not sure.

From: Ryan Sleevi 
Date: Wednesday, October 20, 2021 at 1:35 PM
To: Rich Salz 
Cc: "uta@ietf.org" 
Subject: Re: [Uta] Editorial changes to 6125bis

Hi Rich,

I reviewed these changes, and agree, they look good. Thanks for doing them. I 
left a few comments/suggestions on the GitHub PR for possible clarity, but 
these are not blocking and entirely optional.

On Wed, Oct 20, 2021 at 11:21 AM Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:
I have a number of editorial changes I want to make to the draft.

Most of them are about avoiding redundant terms like “client” instead of 
“interactive or automated client” and CA, etc., instead of “certification 
authority”, etc.  The diffs are big (83 lines added and 95 lines removed, for a 
diff of 440 lines) so I won’t post it here. You can find it at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/34<https://urldefense.com/v3/__https:/github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/34__;!!GjvTz_vk!C1t3iyHAJwT5TeWH-I9Z7fTOxNHFyWW_DydY0fyfGupKB9m8xf0B3mGqNQPb$>
  If anyone has issues or problems with GitHub, let me know and I’ll email it 
to you.


___
Uta mailing list
Uta@ietf.org<mailto:Uta@ietf.org>
https://www.ietf.org/mailman/listinfo/uta<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/uta__;!!GjvTz_vk!C1t3iyHAJwT5TeWH-I9Z7fTOxNHFyWW_DydY0fyfGupKB9m8xf0B3nslZ4CV$>
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 7525bis: recommend RSASSA-PSS in TLS 1.2?

[Salz, Rich]

>Well, we've been thinking specifically about whether to recommend PSS 
for TLS 1.2 implementations and deployments. Naturally you get PSS for 
free if you've upgraded to TLS 1.3, but do we want to say that if you 
haven't upgraded to TLS 1.3 yet you should update your TLS 1.2 
implementation or deployment to add PSS?

No, don't.  It's highly unlike that the TLS 1.2 code will be updated to review 
and check the extra PSS parameters, so it gives you no additional security.  
(It's not clear that many TLS 1.3 implementations do that either)

I find this argument by Peter Gutmann from November 2019 compelling: 
https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html
 

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 7525bis: recommend RSASSA-PSS in TLS 1.2?

[Salz, Rich]

>   This has been my impression, too, but we want to check with the list.

OpenSSL has a comment "/* Only allow PSS for TLS 1.3 */" and it looks like the 
code (tls12_check_peer_sigalg() in ssl/t1_lib.c) enforces that.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 7525bis: recommend RSASSA-PSS in TLS 1.2?

[Salz, Rich]

>So if OpenSSL client connects to server that supports PSS but not
TLS 1.3, the connection will fail because the client vomits at the
server response?

I *think* it will fail cleanly because it gets an ALERT message, but I am not 
sure. I am no longer involved with OpenSSL, I just did a cursory read of the 
source.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [TLS] supported_versions in TLS 1.2

[Salz, Rich]

  *   So, yes, I'd agree there's not much benefit to recommend that a 
TLS-1.2-only implementation add supported_versions, or that an operator look 
for such an implementation. Any implementation-gated effort is better spent 
getting to TLS 1.3.

I agree that if you have supported_versions than you probably also have a 
1.3-capable stack.  But it is also possible to have the first without the 
second. I think the draft might want to separate those two cases.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] 6125bis: proposed new title

[Salz, Rich]

In https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/36

I suggest changing the title to: “On TLS Service Names”

I also added the following to the acknowledgement section. If I left you out, 
please let me know.

+In addition to discussion on the mailing list, the following people
+contributed significant changes:
+Viktor Dukhovni,
+Jim Fenton,
+Olle Johansson,
+and
+Ryan Sleevi.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] 6125bis: multiple identifiers

[Salz, Rich]

Ryan Sleevi has proposed adding the text below to the security considerations 
section.  I’ve posted about this before and had miniscule feedback. Barring 
strong objections, I intend to merge this near the end of the week and publish 
a new draft containing this and the name-change.

## Multiple Presented Identifiers {#security-multi}

A given application service might be addressed by multiple DNS domain names
for a variety of reasons, and a given deployment might service multiple
domains or protocols. TLS Extensions such as TLS Server Name Identification
(SNI), discussed in {{TLS, Section 4.4.2.2}}, and Application Layer Protocol
Negotiation (ALPN), discussed in {{ALPN}}, provide a way for the application
to indicate the desired identifier and protocol to the server, which it
can then used to select the most appropriate certificate.

This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a
certificate.  As a result, an application service can use the same
certificate for multiple hostnames, such as when a client does not support
the TLS SNI extension, or for multiple protocols, such as SMTP and HTTP, on a
single hostname. The use of a single certificate and its keypair in such
environments can make it easier to launch cross-protocol attacks, particularly 
when used in
differing TLS configurations; see, for example, {{ALPACA}} and {{DROWN}}.
Server operators SHOULD take steps to mitigate the risk of cross-protocol
attacks, such as ensuring all TLS endpoints using a given certificate support
exactly the same TLS version(s) and ciphersuite(s), and SHOULD use the TLS
ALPN extension to ensure the correct protocol is used.

## Multiple Reference Identifiers

This specification describes how a client may construct multiple acceptable
reference identifiers, and may match any of those reference identifiers with
the set of presented identifiers. {{PKIX, Section 4.2.1.10}} describes a
mechanism to allow CA certificates to be constrained in the set of presented
identifiers that they may include within server certificates.  However, these
constraints only apply to the explicitly enumerated name forms. For example,
a CA that is only name constrained for DNS-IDs is not constrained for SRV-IDs
and URI-IDs, unless those name forms are also explicitly included within the
name constraints extension.

A client that constructs multiple reference identifiers of different types,
such as both DNS-ID and SRV-IDs, as described in {#verify-reference-rules},
SHOULD take care to ensure that CAs issuing such certificates are
appropriately constrained. This MAY take the form of local policy through
agreement with the issuing CA, or MAY be enforced by the client requiring
that if one form of presented identifier is constrained, such as a dNSName
name constraint for DNS-IDs, then all other forms of acceptable reference
identities are also constrained, such as requiring a uniformResourceIndicator
name constraint for URI-IDs.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 6125bis: proposed new title

[Salz, Rich]

For those not active in GitHub, Martin suggests
-title: On TLS Service Names
+title: Service Names in TLS

I don’t care, although I have a mild preference for the historic “On …” 
construct.

From: Rich Salz 
Date: Tuesday, November 16, 2021 at 2:48 PM
To: "uta@ietf.org" 
Subject: 6125bis: proposed new title

In https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/36

I suggest changing the title to: “On TLS Service Names”
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] 6125bis: proposed new title

[Salz, Rich]

>   Just to elaborate slightly.  I read "On X" as being a dissertation about a 
> subject, whereas the other form reads as being definitive.  I believe we're 
> aiming for definitive in this work and so would prefer to avoid demurring.

Fair comment; changed.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] FW: New Version Notification for draft-ietf-uta-rfc6125bis-04.txt

[Salz, Rich]

This version includes the various editorial changes etc as discussed on-list 
and last week.

It *does not* include the text on multiple identifiers as that discussion still 
seems to be going on.

On 11/18/21, 12:58 PM, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-ietf-uta-rfc6125bis-04.txt
has been successfully submitted by Rich Salz and posted to the
IETF repository.

Name:   draft-ietf-uta-rfc6125bis
Revision:   04
Title:  Service Names in TLS
Document date:  2021-11-18
Group:  uta
Pages:  24
URL:
https://www.ietf.org/archive/id/draft-ietf-uta-rfc6125bis-04.txt 
Status: https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis 
Html:   
https://www.ietf.org/archive/id/draft-ietf-uta-rfc6125bis-04.html 
Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc6125bis
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc6125bis-04

Abstract:
   Many application technologies enable secure communication between two
   entities by means of Transport Layer Security (TLS) with Internet
   Public Key Infrastructure Using X.509 (PKIX) certificates.  This
   document specifies procedures for representing and verifying the
   identity of application services in such interactions.

   This document obsoletes RFC 6125.




The IETF Secretariat



___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt

[Salz, Rich]

I find Viktor's description of the asymmetry between clients and servers to be 
spot-on.

John, could you craft a sample sentence you'd like to see?  Something like this 
as a new sentence at the end of the second paragraph of the "In Scope" section:

In cases where both parties are part of the same administrative domain, 
it MAY be acceptable to have the server enforce the same naming requirements on 
the connecting client. 



___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Some quick comments on some changes in draft-ietf-uta-rfc6125bis-04

[Salz, Rich]

Alexey,

Thanks very much for your comments. I was a little over-zealous :).  Does this 
diff address your concerns?
It's also at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/37

; g diff
diff --git a/draft-ietf-uta-rfc6125bis.md b/draft-ietf-uta-rfc6125bis.md
index bf8eb3d..8f1080e 100644
--- a/draft-ietf-uta-rfc6125bis.md
+++ b/draft-ietf-uta-rfc6125bis.md
@@ -486,9 +486,9 @@ identify a service.
 # Designing Application Protocols {#design}
 
 This section defines how protocol designers should reference this document,
-which MUST be a normative reference in their specification.  The technology
-MUST only use the identifiers defined in this document.  Its specification
-MAY choose to allow only one of them.
+which would typically be a normative reference in their specification.
+Its specification
+MAY choose to allow only one of the identifier types defined here.
 
 If the technology does not use DNS SRV records to resolve the DNS domain
 names of application services then its specification MUST state that SRV-ID
@@ -522,7 +522,7 @@ Note that some of these rules are cumulative
 and can interact in important ways that are illustrated later in this
 document.
 
-1. The certificate MUST include a "DNS-ID" as a baseline
+1. The certificate SHOULD include a "DNS-ID" as a baseline
for interoperability.
 
 2. If the service using the certificate deploys a technology for which


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Some quick comments on some changes in draft-ietf-uta-rfc6125bis-04

[Salz, Rich]

> Thanks very much for your comments. I was a little over-zealous :).  Does 
this diff address your concerns?

>Works for me.

Merged into the editor's copy.  Thanks.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] WGLC for draft-ietf-uta-rfc7525bis-04

[Salz, Rich]

I am reading this now.  It’s good, I like it.

One nit; should Section 4.2 be titled “Cipher Suites for TLS 1.2” ?

In section 6.4, the “(e.g., even more than a few hours)” should probably 
replace it with “(in some cases, even as little as a few hours)” but it would 
be REALLY helpful for guidance on picking the time.

In section 6.5, doesn’t the stapling reference need additions for “cert status” 
for TLS 1.3?  And okay if you don’t want to mention certificate transparency, 
but either include that or make explicit that for XXX reasons you’re not doing 
so.

Hope this helps.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] 7525bis and Certificate Transparency

[Salz, Rich]

On-list discussion of https://github.com/yaronf/I-D/issues/273

This is about section 6.5, “Certificate Revocation”

Starting the bullet list saying “CRLs are the most widely supported mechanism” 
should really have a qualifier.  Something like “While in the general PKI case, 
CRL’s are …”  I mean, if they actually *were* the most widely supported, then 
browsers would do it. :)

More importantly, however, I think this best practices document should say 
something about Certificate Transparency.
For example, the first set of bullets could have something like this:
Certificate Transparency {RFC6962} and {RFC9162} provides a 
mechanism for CA’s and clients to have greater confidence that a certificate 
has been properly issued. As described in {RFC9162, Section 6} CT information 
can be transmitted as extensions during the TLS handshake, often piggy-backed 
with OCSP information. It has similar issues to OCSP as described above.

The numbered set of items could have:
4. Clients MAY wish to support CT, using the mechanisms 
described in {RFC9162}

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] OCSP in RFC7525bis

[Salz, Rich]

  *   We would be grateful for feedback based on implementation experience. In 
particular if you have quantitative data on the use or quality of OCSP that’s 
more recent than Chung18 [3], that would be very useful.

For what it’s worth, *our* customers want OCSP stapling. (It’s enabled by 
default and nobody has turned it off.) Note that if we can’t get an OCSP 
response within a time period, we proceed with the handshake anyway. We are the 
CDN for many responders. We don’t have metrics on when a response is not 
available, nor do we know when such transactions proceeed or close the 
connection, sorry. I guess the takeaway is that server owners seem to like 
this, regardless of what clients do.

Hope this helps.
/r$
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [TLS] OCSP in RFC7525bis

[Salz, Rich]

>I share your skepticism, but i'm still trying to salvage something
useful -- for the purpose of defending against CA malfeasance -- from
the mechanisms we have available.

For that, you mainly want certificate transparency, no?

>   If certificate validation is the process of confirming what a CA says,
then a CA that has said "this certificate should not be considered valid
unless you also have a reasonable proof of freshness" is pretty
unequivocal.

While I like this sentiment, I think there are a couple of arguments against 
it. First, there's the ever-present escape hatch of out of band, or local 
policy. Second, there is the history of poor behavior by some CA's, which leads 
to the primary user agent (browsers, or perhaps TLS runtimes) not being able to 
just completely trust them. Perhaps that historic era has passed, and it is 
time for user agents to end their probation of CA's? Not for me to say.

> But once you're ignoring what the CA actually wrote
and signed in the certificate, you're on your own.

It's not that I'm on my own, but that the user agent is deciding.  Now, I grant 
that the vast majority of users are not capable of making a decision, let alone 
an informed one, but I think it might be useful for us to keep phrasing things 
in terms of user agent.

> The choice about whether to require stapling or not _is_ a policy
> decision relevant not only to server operators, but also relying
> parties, and can be easily abused by CAs if given that lever.

What kind of abuse are you anticipating here?  can you spell it out in
more detail?

+1  I suppose they could DoS their own customers, or upcharge them or something.

And +1 to getting answers to the rest of DKG's questions.  In theory, this note 
shouldn't need any reply :)

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] FW: New Version Notification for draft-ietf-uta-rfc7525bis-05.txt

[Salz, Rich]

I re-read the document.  It's very nice.  A few nits, I think all are editorial 
and can be fixed later. I support moving this doc forward.


I note that you say "use encrypted client hello when it's ready"  Do you want 
to make the same recommendation for DTLS 1.3?

Do you want to say anything about EdDSA and the kerfuffle going on in cfrg@ 
mailing list right now?  No is a good, and probably sane, answer.

4.3 needs a tweak to get {RFC8446, Section 9.1} right.

4.4, do you want to say why 2**24.5 is used for both?  Simpler and therefore 
easier to get right?

5. Should the applicability statement include things like QUIC and NTS?

5. Rather than refer to 2026, I think you should refer to the BCP whatever it 
is.

6.1 Should the references to RFC6125 be changed to the draft 6125bis?

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] FW: New Version Notification for draft-ietf-uta-rfc7525bis-05.txt

[Salz, Rich]

Your answers all make sense.  I think 6125bis is more appropriate than 6125, 
but that would probably mainly depend on publication schedule.

>You and Peter know best.

Do you mind if I show that to my wife? :)


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Second WGLC for draft-ietf-uta-rfc7525bis-05

[Salz, Rich]

  *   I’ve tried to register ALPN for SIP/2.0 for a long time now, but fail to 
get responses and confusing ones.

I don’t recall seeing the request, and I am one of the designated experts for 
the TLS registries.  I wonder where you asked?  
tls-reg-rev...@iana.org is the place to write 
to.  That address doesn’t seem to be written down anywhere well-known.


  *   It seems unclear whether we need to write new RFCs for SIP in order to 
get a registration, but that seems wrong to me.

The requirement is that somewhere there be a stable document.  Since they don’t 
expire, an internet-draft is sufficient.  More likely, if the SIP documents 
talk about TLS, and ideally mention ALPN, that’s enough, just mention whatever 
docs in your email.


  *   It must be much easier to get this done.

Sorry for your frustration.  Perhaps the current draft could add a sentence 
giving the email address?

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Second WGLC for draft-ietf-uta-rfc7525bis-05

[Salz, Rich]

>   In fact if you look up the relevant IANA page [1], it refers to Sec. 17 of 
> RFC 8447, which in turn lists the email address that Rich mentions at 
> iana.org.

You're right.  Every TLS registry has that note.  Ugh, I missed it.  And I 
swear I looked at a registry before my note. (


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Second WGLC for draft-ietf-uta-rfc7525bis-05

[Salz, Rich]

>we'd like to have more explicit confirmation that people are happy with the
way the concerns revealed in the first WGLC were addressed.

Hey, the draft is OK.


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] review of specs that cite RFC 6125

[Salz, Rich]

>* RFC 8314 discusses pinned certificates and points to RFC 6125 for 
further discussion about pinning; although we're removing this text from 
6125bis, the pointer to RFC 6125 will remain valid.

It's not completely removed, but it has fallen out of favor :)  There's still 
text, but it’s just one paragraph at the end of Sec 6.5, and I think 8314 is 
still okay to ref 6125/6125bis.

By the way, this was an amazing effort; thanks!


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] Multiple identifiers in 6125bis

[Salz, Rich]

The only open item left is around “multiple identifiers”  The main (only?) 
people participating in the discussion have been Martin Thomson and Ryan 
Sleevi.  Ryan contributed some text, it got some feedback from Martin.

The email thread started at [1] by Ryan. He proposed some text in an unrelated 
PR [2] that then get put into its own pull request [3]. It had some comments, 
and Martin thinks the Alpaca discussion could be improved [4].

Does anyone object to [3] being merged, and a new issue created to address the 
Alpaca concerns?  Peter and I would like to do so by early next week.

[1] https://mailarchive.ietf.org/arch/msg/uta/EmT_XEKYQbVz50S4XFAhPCVwGbw/
[2] 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/29#discussion_r722367686
[3] https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/33
[4] 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/33#discussion_r834900755
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

[Uta] FW: [Ntp] Wildcards in NTS certificate checking

[Salz, Rich]

A new reader in the NTP working group had some feedback on 6125bis.

>The part that I was looking for was an explicit statement that the "SHOULD 
> NOT 
contain the wildcard" has been dropped.  It might help to add something 
like 
that to the 3rd bullet in section 1.2

I propose to add one sentence:

* Wildcard support is now the default.
  Constrain wildcard certificates so that the wildcard can only
  be the complete left-most component of a domain name.

Does anyone disagree that support for wildcards is the default state of things?

>IP Addresses are out of scope.  I'd like to know more, preferably a 
> sentence 
or paragraph but at least a good reference.  It seems like a good way to 
avoid 
all the security tangles with DNS.

As the draft is about *names* I am not sure what should be done here.  Any 
ideas from the WG? It does say
* Identifiers other than FQDNs.
  Identifiers such as IP address are not discussed. In addition, the focus of 
...

Do we need more rationale?

>Last paragraph before section 4:  "MUST state" that wildcards are not 
supported.  How does that apply to existing RFCs?  Has that item been added 
to 
the reviewers checklist?  I think it would clarify things if future RFCs 
would 
state that wildcards are supported.

The current draft says that if you don't support wildcards you MUST state so in 
your documents. Existing RFCs aren't bound by this draft.  Does anyone think 
this is a problem?

>Section 6.2, last paragraph, matching DNS name and service type.  It's 
probably obvious, but worth stating.  If I'm trying to find a match for 
www:www.example.com or sip:voice.example.com, will that match a certificate 
for sip:www.example.com?

Any suggestions on wording to address this? I think the rules in section 4.1 
are clear, but any thoughts on how to improve it?


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] secdispatched: draft-ciphersuites-in-sec-syslog-01

[Salz, Rich]

>Folks - is there any interest working on this in UTA?

I support adoption.  I'll read and give feedback.  Should be a pretty easy doc 
to finish off.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Multiple identifiers in 6125bis

[Salz, Rich]

Ya got slightly less than 24 hours to complain :)

From: Rich Salz 
Date: Monday, April 18, 2022 at 10:16 AM
To: "uta@ietf.org" 
Subject: Multiple identifiers in 6125bis

The only open item left is around “multiple identifiers”  The main (only?) 
people participating in the discussion have been Martin Thomson and Ryan 
Sleevi.  Ryan contributed some text, it got some feedback from Martin.

The email thread started at [1] by Ryan. He proposed some text in an unrelated 
PR [2] that then get put into its own pull request [3]. It had some comments, 
and Martin thinks the Alpaca discussion could be improved [4].

Does anyone object to [3] being merged, and a new issue created to address the 
Alpaca concerns?  Peter and I would like to do so by early next week.

[1] https://mailarchive.ietf.org/arch/msg/uta/EmT_XEKYQbVz50S4XFAhPCVwGbw/
[2] 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/29#discussion_r722367686
[3] https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/33
[4] 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/33#discussion_r834900755
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] FW: [Ntp] Wildcards in NTS certificate checking

[Salz, Rich]

This is now an open issue 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/44


On 4/19/22, 7:42 PM, "Peter Saint-Andre"  wrote:

On 4/19/22 12:14 PM, Salz, Rich wrote:
> A new reader in the NTP working group had some feedback on 6125bis.
> 
>> The part that I was looking for was an explicit statement that the 
"SHOULD NOT
>  contain the wildcard" has been dropped.  It might help to add 
something like
>  that to the 3rd bullet in section 1.2
> 
> I propose to add one sentence:
> 
> * Wildcard support is now the default.
>Constrain wildcard certificates so that the wildcard can only
>be the complete left-most component of a domain name.

+1

> Does anyone disagree that support for wildcards is the default state of 
things?

Bowing to deployment reality, I agree.

>> IP Addresses are out of scope.  I'd like to know more, preferably a 
sentence
>  or paragraph but at least a good reference.  It seems like a good 
way to avoid
>  all the security tangles with DNS.
> 
> As the draft is about *names* I am not sure what should be done here.  
Any ideas from the WG? It does say
> * Identifiers other than FQDNs.
>Identifiers such as IP address are not discussed. In addition, the 
focus of ...
> 
> Do we need more rationale?

Personally I don't see the need for a rationale (e.g., pointing out the 
percentage of certificates containing IP addresses - IIRC Jeff had some 
numbers on that when we were working on RFC 6125 and it was 1% or less). 
If someone wants to write a specification about IP addresses as names in 
certificates, they are free to do so. In RFC 6125, Jeff and I had to 
limit the scope or the document would have been even longer.

>> Last paragraph before section 4:  "MUST state" that wildcards are not
>  supported.  How does that apply to existing RFCs?  Has that item 
been added to
>  the reviewers checklist?  I think it would clarify things if future 
RFCs would
>  state that wildcards are supported.
> 
> The current draft says that if you don't support wildcards you MUST state 
so in your documents. Existing RFCs aren't bound by this draft.  Does anyone 
think this is a problem?

Having this apply to future documents that cite 6125bis seems fine to me.

>> Section 6.2, last paragraph, matching DNS name and service type.  
It's
>  probably obvious, but worth stating.  If I'm trying to find a match 
for
>  www:www.example.com or sip:voice.example.com, will that match a 
certificate
>  for sip:www.example.com?
> 
> Any suggestions on wording to address this? I think the rules in section 
4.1 are clear, but any thoughts on how to improve it?

Perhaps we should add more examples, specifically to Section 6.4 on 
application service types. As I understand the situation mentioned by 
the original poster, sip:www.example.com (with both domain name and 
application service type) would not result in a match.

Peter

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-05.txt

[Salz, Rich]

This version has a handful of changes since the last draft.  There are a 
handful of editorial improvements (courtesy Martin, Hal, Ryan, Peter, Olle, 
Viktor, Alexey; apologies if I missed anyone). Also the text on "multiple 
identifiers" was merged.

There are now two open issues: some more examples to clear up a confusion from 
Hal, and text/maybe-restructuring around cross-protocol attacks raised by 
Martin.  I really want to resolve these during this month, so we can start WGLC.

On 5/2/22, 11:08 AM, "internet-dra...@ietf.org"  
wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.

Title   : Service Names in TLS
Authors : Peter Saint-Andre
  Jeff Hodges
  Rich Salz
Filename: draft-ietf-uta-rfc6125bis-05.txt
Pages   : 25
Date: 2022-05-02

Abstract:
   Many application technologies enable secure communication between two
   entities by means of Transport Layer Security (TLS) with Internet
   Public Key Infrastructure Using X.509 (PKIX) certificates.  This
   document specifies procedures for representing and verifying the
   identity of application services in such interactions.

   This document obsoletes RFC 6125.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-uta-rfc6125bis-05.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc6125bis-05

Internet-Drafts are also available by rsync at 
rsync.ietf.org::internet-drafts


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-06.txt

[Salz, Rich]

Colleagues,

With this draft we (the authors) think the document is done. We received a lot 
of excellent feedback and comments, and incorporated pretty much all of it. We 
believe this document is ready for WGLC, and ask the chairs to do that.

Depending on what happens during the WGLC, we'll want one minute, or more, to 
present at IETF 114.  

On 5/26/22, 10:11 AM, "internet-dra...@ietf.org"  
wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.

Title   : Service Names in TLS
Authors : Peter Saint-Andre
  Jeff Hodges
  Rich Salz
Filename: draft-ietf-uta-rfc6125bis-06.txt
Pages   : 26
Date: 2022-05-26

Abstract:
   Many application technologies enable secure communication between two
   entities by means of Transport Layer Security (TLS) with Internet
   Public Key Infrastructure Using X.509 (PKIX) certificates.  This
   document specifies procedures for representing and verifying the
   identity of application services in such interactions.

   This document obsoletes RFC 6125.


The IETF datatracker status page for this draft is:
://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/ 

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-uta-rfc6125bis-06.html 

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc6125bis-06 


Internet-Drafts are also available by rsync at 
rsync.ietf.org::internet-drafts

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-06.txt

[Salz, Rich]

Thanks for the review!


  *   - I think QUIC should be mentioned already in section 1.1 and mentioned 
everytime DTLS is mentioned

I made some changes so that things are more “equal” at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/48  Please take a 
look.


  *   - The document use both "Service Name" (title) and "Service Identity" 
(abbreviation). Maybe one of them is enough.

Good catch.  In the same PR I changed the once instance of “Service Name” (in 
the title) to “Service Identity”)

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Extended Master Secret as a MUST in 7525bis

[Salz, Rich]

  *   We are now addressing AD reviews for rfc7525-bis. Ben Kaduk asked why we 
only added TLS 1.2 Extended Master Secret support as a SHOULD, and we tend to 
agree (given widespread support of this feature) that is needs to be a MUST 
[1]. We would appreciate the group’s input before we make this change.

I agree.
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Salz, Rich]

Thanks for the feedback Yaron!

* The DTLS reference should change to DTLS 1.3.

Updated.  Fun factoid, RFC6347 (dtls 1.2) is not RFC9147, 1800 apart. (

* See Appendix A of [VERIFY]

Fixed.

* The rules are brief - it's not clear from the text if this is a summary 
of the totality of the new RFC, or just the changes from the previosu version

Hopefully more clear now.

Here's the diff, also available at 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/50

diff --git a/draft-ietf-uta-rfc6125bis.md b/draft-ietf-uta-rfc6125bis.md
index 1a8fbdd..0c8b011 100644
--- a/draft-ietf-uta-rfc6125bis.md
+++ b/draft-ietf-uta-rfc6125bis.md
@@ -44,7 +44,7 @@ informative:
   ALPN: RFC7301
   DNS-CASE: RFC4343
   DNSSEC: RFC4033
-  DTLS: RFC6347
+  DTLS: RFC9147
   EMAIL-SRV: RFC6186
   NAPTR: RFC3403
   NTS: RFC8915
@@ -195,9 +195,10 @@ to verify the entire certification path as per {{PKIX}}.
 
 The previous version of this specification, {{VERIFY}}, surveyed the 
then-current
 practice from many IETF standards and tried to generalize best practices
-(see Appendix A {{VERIFY}} for details).
+(see Appendix A of {{VERIFY}} for details).
+
 This document takes the lessons learned since then and codifies them.
-The rules are brief:
+The rules defined here are brief:
 
 * Only check DNS domain names via the subjectAlternativeName
   extension designed for that purpose: dNSName.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Salz, Rich]

Does a DANE certificate have the same "name" as a non-DANE certificate?  If the 
subjectAltNAME for a DANE-based certificate is the same as for non-DANE, then 
yes the rules should apply. If not, no.

I cannot answer that question, and look to you experts to advise us.

Note that "validating the chain" is *not* part of 6125 nor 6125bis.  Quoting 
from the Applicability section:
This document addresses only name forms in the leaf "end entity" server
certificate.   It does not address the name forms in the chain of certificates
used to validate a cetrificate, let alone creating or checking the validity
of such a chain.  In order to ensure proper authentication, applications need
to verify the entire certification path as per {{PKIX}}.

Perhaps the last few words could or should be
Such as per {{PKIX}} or {{DANE}}.

But I don't know.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Salz, Rich]

Most items Yaron raised (thanks for the review!)  are addressed in 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/50/files

>> * The DTLS reference should change to DTLS 1.3.
>> * See Appendix A of [VERIFY]
>> * The rules are brief - it's not clear from the text if this is a 
>> summary of the totality of the new RFC, or just the changes from the 
>> previosu version

Also see below.

I'll open new issues and sub-threads for 
Definition of FQDN and non-public and .local names 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/51
XmppAddr https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/52

> * Similarly, it is not clear to me whether certs obtained through 
DANE 
> are in or out of scope.

Well, DANE (RFC 6698) post-dates RFC 6125 so we might need to update 
our 
recommendations to take account of DANE. I'll need to think about the 
exact text we need.

See separate sub-thread with comments by Viktor. He suggests that if needed we 
just say remove "per PKIX" from the last sentence of 1.2:
In order to ensure proper
authentication, applications need to verify the entire certification
path>>> as per [PKIX]<<<.

He is an advocate and expert for DANE, so that is what I did.

Do path validation
> * And the same question for delegated credentials 

There should be nothing to do for this draft. The subcerts document is explicit 
about how the "minted" certificate is just holding a key, and that validation 
should be based on the "original, full" certificate issued to the origin.

> * The Common Name RDN... can appear more than once in the 
subjectName. 
> I'm probably missing something, but how is this different from 
multiple 
> server names appearing in SAN when the certificate protects multiple 
> services?

As it says at the end of Section 2, there are *two* reasons not to use CN. 
First, CN is an untyped text string, and interpretation is ambiguous. Second, 
because of that ambiguity, multiple instances are even more ambiguous; is 
"smtp" really "smtp.example.com":
CN=www.example.com, CN=smtp

>Sorry, should have been clearer. I am referring to this text, that lists 
> two reasons why the Common Name RDN doesn't identify a service. I agree with 
> the first reason but I think the second one is incorrect, because 
> SubjectAltNames have the same property and we still use them.

I changed the second bullet to say:
   It can appear more than once in the subjectName, and the interaction
   of muliple instances is not defined.

Does that address your concern?

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Salz, Rich]

>RFC 6125 (and now 6125bis) are not documents about the definition or 
enforcement of DNS naming rules, only about client-side matching of 
service identifiers presented in X.509 certificates against the client's 
conception of what the service ought to be (i.e., against a reference 
identifier). I see no reason to expand the scope of 6125bis in the 
direction you might be proposing.

I strongly agree.

The current PR, 
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/50/files, does all 
that's needed.  (The diff is trivial to read)
 

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Salz, Rich]

>With regard to PKIX certificates, the primary usage is in the
context of the public key infrastructure described in {{5280}}.
In addition, technologies such as DNS-Based Authentication
of Named Entities (DANE) {{RFC6698}} sometimes use certificates based
on PKIX (more precisely, certificates structured via {{X.509}} or
specific encodings thereof such as {{X.690}}), at least in certain
modes.  Alternatively, a TLS peer could issue delegated credentials
that are based on a CA-issued certificate, as in {{TLS-SUBCERTS}}.
In both of these cases, a TLS client could learn of a service identity
through its inclusion in the relevant certificate.  The rules specified
here are intended to apply whenever service identities are included in
X.509 certificates or credentials that are derived from such certificates.

s/are intended to// :)
s/are derived from/are derived from, or used to derive/ (subverts is the latter)


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Salz, Rich]

>I think this is better: "The rules specified here apply whenever service 
identities are included in X.509 certificates, either directly or 
indirectly through credentials derived from such a certificate."

Work for me!

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Salz, Rich]

Re: https://httpwg.org/specs/rfc9110.html#https.ip-id

6125-bis has always been solely about names, specifically fully-qualified 
domain names. It has not been explicitly discussed, but I think the WG 
understanding is as I just described it.

Looking at the section above, I don't see what 6125bis should have.  I can only 
think of this in "Out of Scope" section 1.4.2:
Identifiers other than FQDNs. Identifiers such as IP address are not 
discussed.
New>> Protocols other than HTTP may want to consider {{RFC9110, Section 
4.3.5}} as a validation model. 

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Salz, Rich]

>   A reference identity of type IP-ID matches if the address is
   identical to an iPAddress value of the subjectAltName extension of
   the certificate.

My concern about this is what I stated before. This document, and its 
predecessor, clearly state that they are about domain names. In particular, 
fully-qualified ones.

Adding IP address is likely to have rippling effects throughout the document. 
For example, much of the Applicability section would need to be revised, the 
simple summary of the rules and the detailed processing sections need an 
"escape hatch", and so on. I believe this document could just point to the HTTP 
RFC as advise for protocols that support IP addresses, as I have also said.

We have not yet seen that there is WG consensus to accommodate Martin's point. 
Can the chairs handle that?  If there is consensus, then the wording needs to 
be discussed and the WGLC should be re-started.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Salz, Rich]

>I found the part "and a DNS domain name of apps.example.net." to be 
confusing, as I initially read it as "the combination of an application 
service type ... and a DNS domain name of apps.example.net.", which is 
not the case according to the following sentence.

So I suggest either removing this part, or changing it to something like 
" and, separately, a DNS domain name of apps.example.net.".

Thanks for the feedback!  Change made.

I am about to merge that change, the other diffs we have discussed on the 
"Yaron" thread, and this change to meet the consensus called by the chairs:
-   Identifiers such as IP address are not discussed. In addition, the focus of
+  Identifiers such as IP address are not discussed.
+  Protocols other than HTTP may want to consider
+  {{HTTP-SEMANTICS, Section 4.3.5}} as a validation model.
+  In addition, the focus of

I'm about to post a new version of the draft.

Thanks everyone for the feedback.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Salz, Rich]

>whether the scope of rfc6125bis draft should be broaden
to include non-domain names, like IP addresses
(at the cost of delaying its publication) or this issue
should be addressed in a separate document.

I am slightly opposed.  My concern is not the delay in publication, but in 
merging the two concepts -- domain names and IP addresses -- into one set of 
rules. First, I don't believe Martin's assertion that IP-ID are very popular; 
we haven't seen them at Akamai, does he have Mozilla telemetry to back this up? 
Second, the clear and simple language in the document has to change a fair 
amount. Martin's PR is only a sketch. It doesn't cover, for example, what 
changes need to be made to 
https://richsalz.github.io/draft-ietf-uta-rfc6125bis/draft-ietf-uta-rfc6125bis.html#name-overview-of-recommendations

Taken together, I think adding IP-ID is a corner case that will make the common 
case harder to understand and implement.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [Last-Call] Secdir telechat review of draft-ietf-uta-rfc7525bis-09

[Salz, Rich]

  *   Every TLS implementation maintains divided codebases for 1.2 vs 1.3. No 
one reads the TLS 1.2 code very closely these days, in my experience

Strongly disagree.  OpenSSL, and its forks do not have a divided codebase.

As for reading the code, I can’t argue with your experience, but in my 
experience this is not the case.

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [Last-Call] Secdir telechat review of draft-ietf-uta-rfc7525bis-09

[Salz, Rich]

  *   It is definitely the "BCP" already--there are good reasons not to support 
TLS 1.2 on a server, and good reasons for clients not to connect to a server 
that negotiates it.

What are they?

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta