On Mon, Feb 24, 2020 at 12:50 PM Christopher Wood <c...@heapingbits.net> wrote:
> 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? > That sounds fine. If I have nits with what's written, I'll suggest text. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
