On Fri, Oct 1, 2021 at 10:07 AM Salz, Rich <rs...@akamai.com> wrote: > 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? >
What sort of ripple effects are you thinking? 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. 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. 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.
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
