On Fri, Feb 21, 2020, at 1:15 PM, Rob Sayre wrote: > > > On Fri, Feb 21, 2020 at 8:35 AM Eric Rescorla <e...@rtfm.com> wrote: > > > > > > On Thu, Feb 20, 2020 at 7:08 PM Rob Sayre <say...@gmail.com> wrote: > >> Hi, > >> > >> I'm not sure how violations of these requirements would result in poor > >> interoperability: > >> > >> Clients which import external keys TLS MUST NOT use these keys for > >> any other purpose. Moreover, each external PSK MUST be associated > >> with at most one hash function. > >> > >> These seem like aspirational security goals. It would be better to > >> describe the consequences of violating these conditions. > > > > I don't agree. They are requirements in order to be able to make the > > assertions we want to make about the security of the protocol. > > > > This is consistent with the following text of RFC 2119 S 6 > > ".. or to limit behavior which has potential for causing harm (e.g., > > limiting retransmisssions) " > > > > I don't think it would be unreasonable.to explain the reason for these, > > though this is already a requirement of 8446 S 4.2.11 (though without > > justification). > > I think that interpretation of 2119 is a stretch, but your idea to add > an explanation while keeping the 2119 terms addresses my concern. At > the very least, the draft should note this is already a requirement of > 8446.
That seems perfectly reasonable! We can point to the security considerations to clarify the "single hash function" requirement, and we can note cross protocol attack deterrence for the other claim. Would that suffice? If not, can you please recommend text? Thanks, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
