Daniel,
Thanks for following up on this (I meant to and dropped the ball). Triminng to
the remaining issue.
spt
> </mglt>
> >> >> > 6. Updates to RFC5246
> >> >> >
> >> >> > [RFC5246], The Transport Layer Security (TLS) Protocol Version 1.2,
> >> >> > suggests that implementations can assume support for MD5 and SHA-1
> >> >> > by
> >> >> > their peer. This update changes the suggestion to assume support
> >> >> > for
> >> >> > SHA-256 instead, due to MD5 and SHA-1 being deprecated.
> >> >> >
> >> >> > In Section 7.4.1.4.1: the text should be revised from:
> >> >> >
> >> >> > OLD:
> >> >> >
> >> >> > "Note: this is a change from TLS 1.1 where there are no explicit
> >> >> > rules, but as a practical matter one can assume that the peer
> >> >> > supports MD5 and SHA- 1."
> >> >> >
> >> >> > NEW:
> >> >> >
> >> >> > "Note: This is a change from TLS 1.1 where there are no explicit
> >> >> > rules, but as a practical matter one can assume that the peer
> >> >> > supports SHA-256."
> >> >> >
> >> >> >
> >> >> > <mglt>
> >> >> > I am reading the Note as an explanation on
> >> >> > why sha was taken as the default hash
> >> >> > function with the following rules.
> >> >> >
> >> >> > """
> >> >> > If the client does not send the signature_algorithms extension, the
> >> >> > server MUST do the following:
> >> >> >
> >> >> > - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
> >> >> > DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
> >> >> > sent the value {sha1,rsa}.
> >> >> >
> >> >> > - If the negotiated key exchange algorithm is one of (DHE_DSS,
> >> >> > DH_DSS), behave as if the client had sent the value {sha1,dsa}.
> >> >> >
> >> >> > - If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
> >> >> > ECDHE_ECDSA), behave as if the client had sent value
> >> >> > {sha1,ecdsa}.
> >> >> > """
> >> >> >
> >> >> > The current document does not update the
> >> >> > default hash function from sha to sha256 to
> >> >> > avoid interoperability issue where one peer
> >> >> > takes sha while the other one takes sha-256.
> >> >>
> >> >> You are right that this section, which is updating TLS1.2 [RFC5246], is
> >> >> not changing the default to SHA-256, but the recommendations for
> >> >> configuring TLS 1.2, which are provided in RFC 7525/BCP 195, is being
> >> >> updated to recommend SHA-256 in the very next section.
> >> >>
> >> > <mglt>
> >> > Updating the update works. It believe that saying a section should be
> >> > remove is not too hard, and it seems to me that mentioning the default
> >> > behaviour is important. I would say that could get implementers confused
> >> > to implement part of the specifications that do not hold any more. I
> >> > would prefer to have this being addressed.
> >> >
> >> > I am reading RFC7525 as recommending a non default parameter while this
> >> > document removed the support of default parameters. So to me the
> >> > updating the status of the default parameters seems more updating the
> >> > 5246 then 7525.
> >> > </mglt>
> >> >
> >> >> > As a results, these rules and the "Note" may
> >> >> > eventually all together be replaced by your
> >> >> > text of section 2.
> >> >> >
> >> >> > The following text may also be removed:
> >> >> >
> >> >> > """
> >> >> > If the client supports only the default hash and signature algorithms
> >> >> > (listed in this section), it MAY omit the signature_algorithms
> >> >> > extension.
> >> >> > """
> >> >>
> >> >> So we might do it, but the question is whether implementers are going
> >> >> to be confused if we don’t do it. I think because s1 already says that
> >> >> client MUST send a signature_algorithms extension that we don’t have to
> >> >> indicate that that particular sentence be dropped/removed from the
> >> >> draft. I will admit this document mixes the two ways to do a bis
> >> >> document, i.e., old/new and describing blanket changes, but I think the
> >> >> intent is pretty clear based on the brevity of the draft.
> >> >>
> >> >
> >> > <mglt>
> >> > I agree we may be able to find all the dots. I think this provides more
> >> > insight to clarify the reading of 5246. I agree the intend is clearly
> >> > stated in the title and section 2 addresses most of it and I believe
> >> > that some flexibility is permitted, but that is unclear to me where to
> >> > put the bar. I still believe that could be easily be addressed.
> >> > </mglt>
> >> >
> <mglt>
> I think I have lost a bit where we are, but I tend to agree that
> clarification of 5246 would be clearer here. That is mentioning the text that
> needs to be removed / changed.
> </mglt>
> <mglt>
> I do not see 07 mentioning the text to be removed - that is now dead text. I
> think that would be clarifying.
> </mglt>
To recap:
You are suggesting that we add the following in s6 before the existing OLD/NEW,
i.e., right after "due to MD5 and SHA-1 being deprecated.":
In Section 7.1.4.1: the following text is removed:
If the client supports only the default hash and signature algorithms
(listed in this section), it MAY omit the signature_algorithms
extension.
Since it’s a MAY, I am a-okay with deleting. Anybody else see harm?
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
