[TLS] Genart last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Meral Shirazipour via Datatracker]

Reviewer: Meral Shirazipour
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-tls-md5-sha1-deprecate-04

Reviewer: Meral Shirazipour
Review Date: 2020-10-26
IETF LC End Date: 2020-10-28
IESG Telechat date: NA

Summary: This draft is ready to be published as Standards Track RFC , no more
comments other than those addressed on the list already.

Major issues:

Minor issues:

Nits/editorial comments:
[Page 4], Section 7, typo : "deprecated.."-->"deprecated."
[Page 4], Section 8, typo :"resgistry"-->"registry"

Best Regards,
Meral


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault via Datatracker]

Reviewer: Daniel Migault
Review result: Ready with Nits

Hi,


I reviewed this document as part of the IoT Directorate's ongoing effort to
review all IETF documents being processed by the IESG.  These comments were
written primarily for the benefit of the Security Area Directors.  Document
authors, document editors, and WG chairs should treat these comments just like
any other IETF Last Call comments.  

Review Results: Ready with Nits

Please find my comments below.

Yours,
Daniel


 Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
  draft-ietf-tls-md5-sha1-deprecate-04
[...]

1.  Introduction

   The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
   specified in [RFC5246].  MD5 and SHA-1 have been proven to be
   insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
   detailed the security considerations, including collision attacks for
   MD5.  NIST formally deprecated use of SHA-1 in 2011
   [NISTSP800-131A-R2] and disallowed its use for digital signatures at
   the end of 2013, based on both the Wang, et. al, attack and the
   potential for brute-force attack.  In 2016, researchers from INRIA
   identified a new class of transcript collision attacks on TLS (and
   other protocols) that rely on efficient collision-finding algorithms
   on the underlying hash constructions [Transcript-Collision].
   Further, in 2017, researchers from Google and CWI Amsterdam
   [SHA-1-Collision] proved SHA-1 collision attacks were practical.
   This document updates [RFC5246] and [RFC7525] in such a way that MD5
   and SHA-1 MUST NOT be used for digital signatures.  However, this
   document does not deprecate SHA-1 in HMAC for record protection.


RFC6194 may be mentioned as a reference for
not deprecating HMAC-SHA-1 as well as an
additional reference to [NISTSP800-131A-R2]. 

Reading the text the situation of HMAC with
MD5 is unclear. Since we specify that SHA-1
is not deprecated for HMAC we may specify
the status for HMAC with MD5. Given RFC6151 I
hope the reason is that MD5 and HMAC-MD5 has
already been deprecated but I have not found
this. Maybe that would worth mentioning it
is deprecated already.



[...]

2.  Signature Algorithms

   Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
   extension.  If a client does not send a signature_algorithms
   extension, then the server MUST abort the handshake and send a
   handshake_failure alert, except when digital signatures are not used
   (for example, when using PSK ciphers).


It seems to me that the server behavior might
be defined as well. In our case this could be
something around the lines the server MUST
ignore MD5 and SHA1 values in the signature
algorithm extension. 



3.  Certificate Request

   Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest
   messages.


It seems to me that the same level of
authentication should be provided for both
peers and that server MUST NOT  include MD5
or SHA-1.

A SHOULD NOT status might be welcome for a
smooth transition. At that time, collision
for MD5 and SHA1 are known for years. It is likely
that software that still need MD5 or SHA1 are
likely to never upgrade, so I doubt a smooth
path worth being taken. 


4.  Server Key Exchange

   Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
   If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange
   message it MUST abort the connection with the illegal_parameter
   alert.


As per section 2, the client has clearly
indicated it does not support signature with
MD5/SHA1, so Server Key Exchange should not
end up with signature with SHA1/MD5. 

"""
If the client has offered the "signature_algorithms" extension, the
   signature algorithm and hash algorithm MUST be a pair listed in that
   extension. 
"""

It also seems to me that the constraint of
including a MD5 and SHA-1 signature is
related to the Certificate. I suspect that
some clarification are needed here.  

Since the case where the extension becomes
mandatory, the quoted text above of RFC 5246
might be updated as well, though this does
not appear that necessary.



5.  Certificate Verify

   Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.
   If a server receives a CertificateVerify message with MD5 or SHA-1 it
   MUST abort the connection with handshake_failure or
   insufficient_security alert.




6. Certificate 

Unless I am missing something, it seems to me
that signature may also be found in the
Certificate messages for the chain as well in
the restriction of the signature algorithm.
The end certificate is associated to the peer
while other certificate are related to a CA. 

It seems that client and server behavior may
be specified. The quoted text below may be
helpful to clarify. 

"""
 If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension.
"""

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault]

To address the comment below, keeping weak security is likely to weaken
current and future IoT communications, so I do not think there is room for
compromise with performance. Of course this is in a context of TLS.  I
expect protocol to leverage from TLS security, so the impact should be
rather negligible.

"""
As those hash algorithms were 'cheap' for TLS 1.2, I would appreciate a
review of impacted IoT protocols if those algorithms are deprecated.
"""
Yours,
Daniel


On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Daniel Migault
> Review result: Ready with Nits
>
> Hi,
>
>
> I reviewed this document as part of the IoT Directorate's ongoing effort to
> review all IETF documents being processed by the IESG.  These comments were
> written primarily for the benefit of the Security Area Directors.  Document
> authors, document editors, and WG chairs should treat these comments just
> like
> any other IETF Last Call comments.
>
> Review Results: Ready with Nits
>
> Please find my comments below.
>
> Yours,
> Daniel
>
>
>  Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
>   draft-ietf-tls-md5-sha1-deprecate-04
> [...]
>
> 1.  Introduction
>
>The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
>specified in [RFC5246].  MD5 and SHA-1 have been proven to be
>insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
>detailed the security considerations, including collision attacks for
>MD5.  NIST formally deprecated use of SHA-1 in 2011
>[NISTSP800-131A-R2] and disallowed its use for digital signatures at
>the end of 2013, based on both the Wang, et. al, attack and the
>potential for brute-force attack.  In 2016, researchers from INRIA
>identified a new class of transcript collision attacks on TLS (and
>other protocols) that rely on efficient collision-finding algorithms
>on the underlying hash constructions [Transcript-Collision].
>Further, in 2017, researchers from Google and CWI Amsterdam
>[SHA-1-Collision] proved SHA-1 collision attacks were practical.
>This document updates [RFC5246] and [RFC7525] in such a way that MD5
>and SHA-1 MUST NOT be used for digital signatures.  However, this
>document does not deprecate SHA-1 in HMAC for record protection.
>
> 
> RFC6194 may be mentioned as a reference for
> not deprecating HMAC-SHA-1 as well as an
> additional reference to [NISTSP800-131A-R2].
>
> Reading the text the situation of HMAC with
> MD5 is unclear. Since we specify that SHA-1
> is not deprecated for HMAC we may specify
> the status for HMAC with MD5. Given RFC6151 I
> hope the reason is that MD5 and HMAC-MD5 has
> already been deprecated but I have not found
> this. Maybe that would worth mentioning it
> is deprecated already.
>
> 
>
> [...]
>
> 2.  Signature Algorithms
>
>Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
>extension.  If a client does not send a signature_algorithms
>extension, then the server MUST abort the handshake and send a
>handshake_failure alert, except when digital signatures are not used
>(for example, when using PSK ciphers).
>
> 
> It seems to me that the server behavior might
> be defined as well. In our case this could be
> something around the lines the server MUST
> ignore MD5 and SHA1 values in the signature
> algorithm extension.
>
> 
>
> 3.  Certificate Request
>
>Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest
>messages.
>
> 
> It seems to me that the same level of
> authentication should be provided for both
> peers and that server MUST NOT  include MD5
> or SHA-1.
>
> A SHOULD NOT status might be welcome for a
> smooth transition. At that time, collision
> for MD5 and SHA1 are known for years. It is likely
> that software that still need MD5 or SHA1 are
> likely to never upgrade, so I doubt a smooth
> path worth being taken.
> 
>
> 4.  Server Key Exchange
>
>Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
>If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange
>message it MUST abort the connection with the illegal_parameter
>alert.
>
> 
> As per section 2, the client has clearly
> indicated it does not support signature with
> MD5/SHA1, so Server Key Exchange should not
> end up with signature with SHA1/MD5.
>
> """
> If the client has offered the "signature_algorithms" extension, the
>signature algorithm and hash algorithm MUST be a pair listed in that
>extension.
> """
>
> It also seems to me that the constraint of
> including a MD5 and SHA-1 signature is
> related to the Certificate. I suspect that
> some clarification are needed here.
>
> Since the case where the extension becomes
> mandatory, the quoted text above of RFC 5246
> might be updated as well, though this does
> not appear that necessary.
>
> 
>
> 5.  Certificate Verify
>
>Clients MUST NOT include MD5 and SHA-1 i

[TLS] ECH test server

[Chris Box (BT)]

Hi,

I would like to test an ECH-enabled client, but am struggling to find a
public test server with a published ECHconfig in its HTTPS record.

Do any yet exist?

I've looked in all these places, but none are mentioned:
https://github.com/tlswg/draft-ietf-tls-esni/wiki/Implementation-Status
https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md
https://github.com/tlswg/tlswg-wiki/blob/master/TESTING.md

Or is everyone just spinning up private servers for now?

Thanks,
Chris
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] ECH & HPKE versions as an example of too much githubbery

[Stephen Farrell]

Hiya,

The latest ECH draft from Oct 16 says "ECH uses draft-05 of
HPKE for public key encryption."

The latest HPKE draft (-06) from Oct 23 has a few minor
incompatible changes (for good but relatively trivial
reasons).

So for interop ECH apparently requires use of an outdated
I-D, despite the one week difference in publishing and
a common co-author.

It seems a bit mad that all that githubbery results in
such a lack of co-ordination in two closely related
specs.

Anyway, I can manage to handle both HPKE-05 and
HPKE-06 but this seems like yet another case where
there is too much githubbery going on with the result
that two closely linked drafts with a common co-author
end up out of whack despite being issued within a week
of one another.

That and the velocity of discussion and changes on
github are a major disincentive (for me) for implementing
ECH. I simply do not have the cycles to keep up with it
as it has been happening these last months. If that were
the goal of the authors and those endlessly commenting on
github (and I do not believe it is), then they would be
close to reaching that goal.

Can we not please freeze this stuff for at least long
enough to get implementations done and somewhat tested?

Frankly, I expect my plea here to be more or less ignored
just as my previous entreaties were. I decided to send
it anyway on the basis that the perhaps what seems like
an obvious failure of the current approach (ECH can't
interop unless you use an outdated I-D for HPKE) might
show that all this apparent high velocity discussion on
github is not as effetcive as claimed (in at least this
case).

Thanks,
Stephen.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH test server

[Stephen Farrell]

On 27/10/2020 18:37, Chris Box (BT) wrote:

Hi,

I would like to test an ECH-enabled client, but am struggling to find a
public test server with a published ECHconfig in its HTTPS record.

Do any yet exist?

I've looked in all these places, but none are mentioned:
https://github.com/tlswg/draft-ietf-tls-esni/wiki/Implementation-Status
https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md
https://github.com/tlswg/tlswg-wiki/blob/master/TESTING.md

Or is everyone just spinning up private servers for now?


I got as far as draft-05 before falling behind sorry.
Will post when/if I get current.

See my other mail for the related whine:-)

Cheers,
S.



Thanks,
Chris


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

[Mark Nottingham]

Stephen,

I don't think what you're complaining about can be attributed to GitHub. Tools 
are just tools, how they're used is what's relevant (i.e., this could just as 
easily happen over e-mail).

Cheers,


> On 28 Oct 2020, at 7:31 am, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
> The latest ECH draft from Oct 16 says "ECH uses draft-05 of
> HPKE for public key encryption."
> 
> The latest HPKE draft (-06) from Oct 23 has a few minor
> incompatible changes (for good but relatively trivial
> reasons).
> 
> So for interop ECH apparently requires use of an outdated
> I-D, despite the one week difference in publishing and
> a common co-author.
> 
> It seems a bit mad that all that githubbery results in
> such a lack of co-ordination in two closely related
> specs.
> 
> Anyway, I can manage to handle both HPKE-05 and
> HPKE-06 but this seems like yet another case where
> there is too much githubbery going on with the result
> that two closely linked drafts with a common co-author
> end up out of whack despite being issued within a week
> of one another.
> 
> That and the velocity of discussion and changes on
> github are a major disincentive (for me) for implementing
> ECH. I simply do not have the cycles to keep up with it
> as it has been happening these last months. If that were
> the goal of the authors and those endlessly commenting on
> github (and I do not believe it is), then they would be
> close to reaching that goal.
> 
> Can we not please freeze this stuff for at least long
> enough to get implementations done and somewhat tested?
> 
> Frankly, I expect my plea here to be more or less ignored
> just as my previous entreaties were. I decided to send
> it anyway on the basis that the perhaps what seems like
> an obvious failure of the current approach (ECH can't
> interop unless you use an outdated I-D for HPKE) might
> show that all this apparent high velocity discussion on
> github is not as effetcive as claimed (in at least this
> case).
> 
> Thanks,
> Stephen.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--
Mark Nottingham   https://www.mnot.net/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

[Stephen Farrell]

Hiya,

On 27/10/2020 22:28, Mark Nottingham wrote:

Stephen,

I don't think what you're complaining about can be attributed to
GitHub. Tools are just tools, how they're used is what's relevant
(i.e., this could just as easily happen over e-mail).


Sorta. I doubt the volume of traffic would've happened via
email for non-contentious, not-trivial-but-not-earthshaking
topics.

I "watch" the repos for these drafts, and in just the last
month, I've seen 401 esni emails, 127 hpke emails and 157
dns-alt-svc emails. That's too many, is encouraged by the
tools IMO and has to mean a lot not being discussed on the
list that ought be.

So I do think the tooling is really part of this. But yes,
had someone taken on the mega-task of bringing the useful
bits of those 683 mails per month to the list, it may have
been that the mismatch would've been avoided.

Cheers,
S.

PS: I neglected to say in my earlier mail that hpke-05 has
an interop bug that we discovered when I was verifying the
test vectors a few months ago. It's not the right basis to
pick if we want esni-08 to be used for interop really. But
more to the point, nor is a moving target.




Cheers,



On 28 Oct 2020, at 7:31 am, Stephen Farrell
 wrote:


Hiya,

The latest ECH draft from Oct 16 says "ECH uses draft-05 of HPKE
for public key encryption."

The latest HPKE draft (-06) from Oct 23 has a few minor 
incompatible changes (for good but relatively trivial reasons).


So for interop ECH apparently requires use of an outdated I-D,
despite the one week difference in publishing and a common
co-author.

It seems a bit mad that all that githubbery results in such a lack
of co-ordination in two closely related specs.

Anyway, I can manage to handle both HPKE-05 and HPKE-06 but this
seems like yet another case where there is too much githubbery
going on with the result that two closely linked drafts with a
common co-author end up out of whack despite being issued within a
week of one another.

That and the velocity of discussion and changes on github are a
major disincentive (for me) for implementing ECH. I simply do not
have the cycles to keep up with it as it has been happening these
last months. If that were the goal of the authors and those
endlessly commenting on github (and I do not believe it is), then
they would be close to reaching that goal.

Can we not please freeze this stuff for at least long enough to get
implementations done and somewhat tested?

Frankly, I expect my plea here to be more or less ignored just as
my previous entreaties were. I decided to send it anyway on the
basis that the perhaps what seems like an obvious failure of the
current approach (ECH can't interop unless you use an outdated I-D
for HPKE) might show that all this apparent high velocity
discussion on github is not as effetcive as claimed (in at least
this case).

Thanks, Stephen.

___ TLS mailing list 
TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls


-- Mark Nottingham   https://www.mnot.net/



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

[Eric Rescorla]

On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 27/10/2020 22:28, Mark Nottingham wrote:
> > Stephen,
> >
> > I don't think what you're complaining about can be attributed to
> > GitHub. Tools are just tools, how they're used is what's relevant
> > (i.e., this could just as easily happen over e-mail).
>
> Sorta. I doubt the volume of traffic would've happened via
> email for non-contentious, not-trivial-but-not-earthshaking
> topics.
>
> I "watch" the repos for these drafts, and in just the last
> month, I've seen 401 esni emails, 127 hpke emails and 157
> dns-alt-svc emails. That's too many, is encouraged by the
> tools IMO and has to mean a lot not being discussed on the
> list that ought be.
>
> So I do think the tooling is really part of this. But yes,
> had someone taken on the mega-task of bringing the useful
> bits of those 683 mails per month to the list, it may have
> been that the mismatch would've been avoided.
>

This seems to me like it makes the argument for the tooling. Namely that it
enables low friction participation on details.



> PS: I neglected to say in my earlier mail that hpke-05 has
> an interop bug that we discovered when I was verifying the
> test vectors a few months ago. It's not the right basis to
> pick if we want esni-08 to be used for interop really. But
> more to the point, nor is a moving target.
>

I think this is the key point. ECH is under active development with open
issues. Trying to do interop now is at your own risk.

-Ekr


>
> >
> > Cheers,
> >
> >
> >> On 28 Oct 2020, at 7:31 am, Stephen Farrell
> >>  wrote:
> >>
> >>
> >> Hiya,
> >>
> >> The latest ECH draft from Oct 16 says "ECH uses draft-05 of HPKE
> >> for public key encryption."
> >>
> >> The latest HPKE draft (-06) from Oct 23 has a few minor
> >> incompatible changes (for good but relatively trivial reasons).
> >>
> >> So for interop ECH apparently requires use of an outdated I-D,
> >> despite the one week difference in publishing and a common
> >> co-author.
> >>
> >> It seems a bit mad that all that githubbery results in such a lack
> >> of co-ordination in two closely related specs.
> >>
> >> Anyway, I can manage to handle both HPKE-05 and HPKE-06 but this
> >> seems like yet another case where there is too much githubbery
> >> going on with the result that two closely linked drafts with a
> >> common co-author end up out of whack despite being issued within a
> >> week of one another.
> >>
> >> That and the velocity of discussion and changes on github are a
> >> major disincentive (for me) for implementing ECH. I simply do not
> >> have the cycles to keep up with it as it has been happening these
> >> last months. If that were the goal of the authors and those
> >> endlessly commenting on github (and I do not believe it is), then
> >> they would be close to reaching that goal.
> >>
> >> Can we not please freeze this stuff for at least long enough to get
> >> implementations done and somewhat tested?
> >>
> >> Frankly, I expect my plea here to be more or less ignored just as
> >> my previous entreaties were. I decided to send it anyway on the
> >> basis that the perhaps what seems like an obvious failure of the
> >> current approach (ECH can't interop unless you use an outdated I-D
> >> for HPKE) might show that all this apparent high velocity
> >> discussion on github is not as effetcive as claimed (in at least
> >> this case).
> >>
> >> Thanks, Stephen.
> >>
> >> ___ TLS mailing list
> >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> >
> > -- Mark Nottingham   https://www.mnot.net/
> >
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

[Stephen Farrell]

Hiya,

On 27/10/2020 23:06, Eric Rescorla wrote:

On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell
 wrote:



Hiya,

On 27/10/2020 22:28, Mark Nottingham wrote:

Stephen,

I don't think what you're complaining about can be attributed to 
GitHub. Tools are just tools, how they're used is what's

relevant (i.e., this could just as easily happen over e-mail).


Sorta. I doubt the volume of traffic would've happened via email
for non-contentious, not-trivial-but-not-earthshaking topics.

I "watch" the repos for these drafts, and in just the last month,
I've seen 401 esni emails, 127 hpke emails and 157 dns-alt-svc
emails. That's too many, is encouraged by the tools IMO and has to
mean a lot not being discussed on the list that ought be.

So I do think the tooling is really part of this. But yes, had
someone taken on the mega-task of bringing the useful bits of those
683 mails per month to the list, it may have been that the mismatch
would've been avoided.



This seems to me like it makes the argument for the tooling. Namely
that it enables low friction participation on details.


It enables that for *some* whose workflow that matches.
That is not the IETF process (yet). (And "low friction"
is just as much verbiage as it would be had I described
the situation using a term like "verbal diarrhoea":-)


PS: I neglected to say in my earlier mail that hpke-05 has an
interop bug that we discovered when I was verifying the test
vectors a few months ago. It's not the right basis to pick if we
want esni-08 to be used for interop really. But more to the point,
nor is a moving target.



I think this is the key point. ECH is under active development with
open issues. 


No. The key point is esni-08 unnecessarily and uselessly
depends on -05 which has a known bug. That should have
been avoided. That it was not is a fail. And I think one
party due to the preferred tooling of the set of people
who are extremely active on github wrt these drafts. (It's
not an end of the world thing, but denying it seems a
bit odd to me.)


Trying to do interop now is at your own risk.


That's a non-answer. I didn't claim any loss so risk isn't
relevant. It's being denied the opportunity to implement by
the continually moving target that is my problem, not a
risk nor financial loss.

Mozilla implemented -02, but not, so far as I recall, later
versions. It's been two years since -02 was published. I don't think 
we've come that far at all since (there are

modest improvements but not two years worth) and I do
think the tooling is responsible for some of those delays,
certainly this year.

ISTM that a spec that always changes too fast to be
implemented by many will often be inferior to one that is
dealt with in a manner that has more eyeballs looking at
it in considered detail. So by all means use github, but
at least make sure the text has enough stability to be
coded up.

Cheers,
S.



-Ekr






Cheers,


On 28 Oct 2020, at 7:31 am, Stephen Farrell 
 wrote:



Hiya,

The latest ECH draft from Oct 16 says "ECH uses draft-05 of
HPKE for public key encryption."

The latest HPKE draft (-06) from Oct 23 has a few minor 
incompatible changes (for good but relatively trivial

reasons).

So for interop ECH apparently requires use of an outdated I-D, 
despite the one week difference in publishing and a common 
co-author.


It seems a bit mad that all that githubbery results in such a
lack of co-ordination in two closely related specs.

Anyway, I can manage to handle both HPKE-05 and HPKE-06 but
this seems like yet another case where there is too much
githubbery going on with the result that two closely linked
drafts with a common co-author end up out of whack despite
being issued within a week of one another.

That and the velocity of discussion and changes on github are
a major disincentive (for me) for implementing ECH. I simply do
not have the cycles to keep up with it as it has been happening
these last months. If that were the goal of the authors and
those endlessly commenting on github (and I do not believe it
is), then they would be close to reaching that goal.

Can we not please freeze this stuff for at least long enough to
get implementations done and somewhat tested?

Frankly, I expect my plea here to be more or less ignored just
as my previous entreaties were. I decided to send it anyway on
the basis that the perhaps what seems like an obvious failure
of the current approach (ECH can't interop unless you use an
outdated I-D for HPKE) might show that all this apparent high
velocity discussion on github is not as effetcive as claimed
(in at least this case).

Thanks, Stephen.

___ TLS mailing
list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls


-- Mark Nottingham   https://www.mnot.net/

___ TLS mailing list 
TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls






OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_s

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

[Eric Rescorla]

On Tue, Oct 27, 2020 at 4:20 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 27/10/2020 23:06, Eric Rescorla wrote:
> > On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell
> >  wrote:
> >
> >>
> >> Hiya,
> >>
> >> On 27/10/2020 22:28, Mark Nottingham wrote:
> >>> Stephen,
> >>>
> >>> I don't think what you're complaining about can be attributed to
> >>> GitHub. Tools are just tools, how they're used is what's
> >>> relevant (i.e., this could just as easily happen over e-mail).
> >>
> >> Sorta. I doubt the volume of traffic would've happened via email
> >> for non-contentious, not-trivial-but-not-earthshaking topics.
> >>
> >> I "watch" the repos for these drafts, and in just the last month,
> >> I've seen 401 esni emails, 127 hpke emails and 157 dns-alt-svc
> >> emails. That's too many, is encouraged by the tools IMO and has to
> >> mean a lot not being discussed on the list that ought be.
> >>
> >> So I do think the tooling is really part of this. But yes, had
> >> someone taken on the mega-task of bringing the useful bits of those
> >> 683 mails per month to the list, it may have been that the mismatch
> >> would've been avoided.
> >>
> >
> > This seems to me like it makes the argument for the tooling. Namely
> > that it enables low friction participation on details.
>
> It enables that for *some* whose workflow that matches.
> That is not the IETF process (yet).


In fact, it *is* the IETF process, or rather one permitted IETF process,
since RFC 8874. If you think the chairs are not following the IETF process,
I would encourage you to contact the AD rather than arguing with me.


> Trying to do interop now is at your own risk.
>
> That's a non-answer. I didn't claim any loss so risk isn't
> relevant. It's being denied the opportunity to implement by
> the continually moving target that is my problem, not a
> risk nor financial loss.
>

And what I'm saying here is that specifications go through stages where
they are stable enough to implement and other stages where they are in flux
and people should hold off on implementing, or at least trying to get
interop. Currently, we are in the latter period.


Mozilla implemented -02, but not, so far as I recall, later
> versions. It's been two years since -02 was published.


Yes. We've been waiting for the spec to stabilize to the point where it was
worth cutting a new version. We are now working on that.



> I don't think
> we've come that far at all since (there are
> modest improvements but not two years worth) and I do
> think the tooling is responsible for some of those delays,
> certainly this year.
>

Yes, I appreciate that that's your opinion. It's not mine.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

[Salz, Rich]

>I don't think what you're complaining about can be attributed to GitHub. 
> Tools are just tools, how they're used is what's relevant (i.e., this could 
> just as easily happen over e-mail).

Frictionless and increased speed can be its own drawback.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

[Stephen Farrell]

On 27/10/2020 23:27, Eric Rescorla wrote:


In fact, it*is*  the IETF process, or rather one permitted IETF process,
since RFC 8874. 


I don't believe the current case matches my recollection of
that, but I've not checked in detail. The lack of list
discussion certainly smells wrong to me.


If you think the chairs are not following the IETF process,
I would encourage you to contact the AD rather than arguing with me.


I am not arguing with you. I am discussing an avoidable spec
bug, and how that might've happened, on the TLS WG list.

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Michael Richardson]

<#secure method=pgpmime mode=sign>

Daniel Migault via Datatracker  wrote:
> RFC6194 may be mentioned as a reference for
> not deprecating HMAC-SHA-1 as well as an
> additional reference to [NISTSP800-131A-R2].

> Reading the text the situation of HMAC with
> MD5 is unclear. Since we specify that SHA-1
> is not deprecated for HMAC we may specify
> the status for HMAC with MD5. Given RFC6151 I
> hope the reason is that MD5 and HMAC-MD5 has
> already been deprecated but I have not found
> this. Maybe that would worth mentioning it
> is deprecated already.

My understanding is that despite the flaws in MD5, HMAC-MD5 is still
resistant to second pre-image attacks.
RFC6151 is pretty clear about the state of things, but let me tell you about
the hassle of explaining this to end users.
The two rounds that the HMAC construct uses mean that only way to get past it
is with a brute force attack.

I rememeber back in 1995ish, when Hugo insisted with do HMAC.
We hated it because it made hardware.  He clearly knew something!

I agree that this document should probably quote more of RFC6151 when it
comes to HMAC-MD5.

My best advice for why we deprecate HMAC-MD5 (and HMAC-SHA1) is because end
users are confused and/or alarmed if the strings "MD5" or "SHA1" occur in
their logs.

Certainly from an IOT point of view, an algorithm that has no code is more
secure than one with code.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

[Sean Turner]

Stephen,

Given that there appears to be emerging consensus around the "issue discussion 
mode with email summaries sounds" presented in Chris' email from just last week 
can we let that settle?

We can certainly get a summary together - granted there have been interim 
meetings with published minutes [0][1].

We could also adopt an approach similar to the QUIC WG where they would declare 
a particular draft version one that they would run interop on. We would need to 
decide on the process of declaring what that version was as well as moving to 
the next version.

spt

[0] https://datatracker.ietf.org/doc/minutes-interim-2020-tls-02-202009031000/
[1] https://datatracker.ietf.org/doc/minutes-interim-2020-tls-03-202009210800/

> On Oct 27, 2020, at 16:31, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
> The latest ECH draft from Oct 16 says "ECH uses draft-05 of
> HPKE for public key encryption."
> 
> The latest HPKE draft (-06) from Oct 23 has a few minor
> incompatible changes (for good but relatively trivial
> reasons).
> 
> So for interop ECH apparently requires use of an outdated
> I-D, despite the one week difference in publishing and
> a common co-author.
> 
> It seems a bit mad that all that githubbery results in
> such a lack of co-ordination in two closely related
> specs.
> 
> Anyway, I can manage to handle both HPKE-05 and
> HPKE-06 but this seems like yet another case where
> there is too much githubbery going on with the result
> that two closely linked drafts with a common co-author
> end up out of whack despite being issued within a week
> of one another.
> 
> That and the velocity of discussion and changes on
> github are a major disincentive (for me) for implementing
> ECH. I simply do not have the cycles to keep up with it
> as it has been happening these last months. If that were
> the goal of the authors and those endlessly commenting on
> github (and I do not believe it is), then they would be
> close to reaching that goal.
> 
> Can we not please freeze this stuff for at least long
> enough to get implementations done and somewhat tested?
> 
> Frankly, I expect my plea here to be more or less ignored
> just as my previous entreaties were. I decided to send
> it anyway on the basis that the perhaps what seems like
> an obvious failure of the current approach (ECH can't
> interop unless you use an outdated I-D for HPKE) might
> show that all this apparent high velocity discussion on
> github is not as effetcive as claimed (in at least this
> case).
> 
> Thanks,
> Stephen.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Sean Turner]

> On Oct 27, 2020, at 19:44, Michael Richardson  wrote:
> 
> 
> <#secure method=pgpmime mode=sign>
> 
> Daniel Migault via Datatracker  wrote:
>> RFC6194 may be mentioned as a reference for
>> not deprecating HMAC-SHA-1 as well as an
>> additional reference to [NISTSP800-131A-R2].
> 
>> Reading the text the situation of HMAC with
>> MD5 is unclear. Since we specify that SHA-1
>> is not deprecated for HMAC we may specify
>> the status for HMAC with MD5. Given RFC6151 I
>> hope the reason is that MD5 and HMAC-MD5 has
>> already been deprecated but I have not found
>> this. Maybe that would worth mentioning it
>> is deprecated already.
> 
> My understanding is that despite the flaws in MD5, HMAC-MD5 is still
> resistant to second pre-image attacks.
> RFC6151 is pretty clear about the state of things,

Well it was the state of things in 2011. But, I am pretty sure we have heard 
something by now (or this thread will prompt a response from somebody who knows 
more).

> but let me tell you about
> the hassle of explaining this to end users.
> The two rounds that the HMAC construct uses mean that only way to get past it
> is with a brute force attack.
> 
> I rememeber back in 1995ish, when Hugo insisted with do HMAC.
> We hated it because it made hardware.  He clearly knew something!
> 
> I agree that this document should probably quote more of RFC6151 when it
> comes to HMAC-MD5.
> 
> My best advice for why we deprecate HMAC-MD5 (and HMAC-SHA1) is because end
> users are confused and/or alarmed if the strings "MD5" or "SHA1" occur in
> their logs.


This was the reason I wrote RFC 7093 (Additional Methods for Generating Key 
Identifiers Values), which ended up going through the ISE stream. I wanted to 
avoid having to explain that key identifiers were generated with SHA-1 but that 
was okay. Better to just avoid the darn algorithm.

spt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH & HPKE versions as an example of too much githubbery

[Stephen Farrell]

Hiya,

On 28/10/2020 00:32, Sean Turner wrote:

Stephen,

Given that there appears to be emerging consensus around the "issue
discussion mode with email summaries sounds" presented in Chris'
email from just last week can we let that settle?


My bet is that yes the WG will land on that bad answer.
I contend that it is highly unlikely useful summaries of
the barrage of githubbery can be regularly generated,
unless some of those messaging there decide to send mail
to the list as needed and allow time for responses from
those with other things to do that hour. (That's not a
thing within WG chairs' power to grant of course but it
would be nice.)

I'd be much happier about all that if someone would go
back and do that summarising for e.g. the last month's
traffic. I suspect that poor person would find the task
hard or maybe give up. I encourage anyone to take a look
and see how easy/hard they think that might be.

(Just to be clear: I don't think anyone here is trying to
be a bad actor - I figure it's more a case of understandably
not taking into account that there are more people involved
in the WG's work than are active in a particular way on
github. Still, there is "not taking into account" going
on, so not all's well.)


We can certainly get a summary together - granted there have been
interim meetings with published minutes [0][1].


Those are fine. No complaint from me there. (Albeit that
I had to miss some, but that was my problem.)


We could also adopt an approach similar to the QUIC WG where they
would declare a particular draft version one that they would run
interop on. We would need to decide on the process of declaring what
that version was as well as moving to the next version.


I think that would be good, yes. Just pick some iterations
and get agreement that enough people will implement and do
enough testing to be useful and take enough results into
account in the next iteration. Lotsa judgement needed but not
a showstopper. Way better than the current situation IMO so
yes please try direct us in that direction if you can.

Cheers,
S.

PS: I got another 8 mails wrt the esni draft since I sent
the earlier numbers. One of those had some human readable
content maybe, though it was context-free in that context;-)




spt

[0]
https://datatracker.ietf.org/doc/minutes-interim-2020-tls-02-202009031000/


[1] 
https://datatracker.ietf.org/doc/minutes-interim-2020-tls-03-202009210800/



On Oct 27, 2020, at 16:31, Stephen Farrell
 wrote:


Hiya,

The latest ECH draft from Oct 16 says "ECH uses draft-05 of HPKE
for public key encryption."

The latest HPKE draft (-06) from Oct 23 has a few minor 
incompatible changes (for good but relatively trivial reasons).


So for interop ECH apparently requires use of an outdated I-D,
despite the one week difference in publishing and a common
co-author.

It seems a bit mad that all that githubbery results in such a lack
of co-ordination in two closely related specs.

Anyway, I can manage to handle both HPKE-05 and HPKE-06 but this
seems like yet another case where there is too much githubbery
going on with the result that two closely linked drafts with a
common co-author end up out of whack despite being issued within a
week of one another.

That and the velocity of discussion and changes on github are a
major disincentive (for me) for implementing ECH. I simply do not
have the cycles to keep up with it as it has been happening these
last months. If that were the goal of the authors and those
endlessly commenting on github (and I do not believe it is), then
they would be close to reaching that goal.

Can we not please freeze this stuff for at least long enough to get
implementations done and somewhat tested?

Frankly, I expect my plea here to be more or less ignored just as
my previous entreaties were. I decided to send it anyway on the
basis that the perhaps what seems like an obvious failure of the
current approach (ECH can't interop unless you use an outdated I-D
for HPKE) might show that all this apparent high velocity
discussion on github is not as effetcive as claimed (in at least
this case).

Thanks, Stephen.

___ TLS mailing list 
TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls




OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Sean Turner]

Please note the comment about Section 3 suggests changing server behavior from 
SHOULD NOT to a MUST NOT.

> On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker  
> wrote:
> 
> Reviewer: Daniel Migault
> Review result: Ready with Nits
> 
> Hi,
> 
> 
> I reviewed this document as part of the IoT Directorate's ongoing effort to
> review all IETF documents being processed by the IESG.  These comments were
> written primarily for the benefit of the Security Area Directors.  Document
> authors, document editors, and WG chairs should treat these comments just like
> any other IETF Last Call comments.  
> 
> Review Results: Ready with Nits
> 
> Please find my comments below.
> 
> Yours,
> Daniel
> 
> 
> Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
>  draft-ietf-tls-md5-sha1-deprecate-04
> [...]
> 
> 1.  Introduction
> 
>   The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
>   specified in [RFC5246].  MD5 and SHA-1 have been proven to be
>   insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
>   detailed the security considerations, including collision attacks for
>   MD5.  NIST formally deprecated use of SHA-1 in 2011
>   [NISTSP800-131A-R2] and disallowed its use for digital signatures at
>   the end of 2013, based on both the Wang, et. al, attack and the
>   potential for brute-force attack.  In 2016, researchers from INRIA
>   identified a new class of transcript collision attacks on TLS (and
>   other protocols) that rely on efficient collision-finding algorithms
>   on the underlying hash constructions [Transcript-Collision].
>   Further, in 2017, researchers from Google and CWI Amsterdam
>   [SHA-1-Collision] proved SHA-1 collision attacks were practical.
>   This document updates [RFC5246] and [RFC7525] in such a way that MD5
>   and SHA-1 MUST NOT be used for digital signatures.  However, this
>   document does not deprecate SHA-1 in HMAC for record protection.
> 
> 
> RFC6194 may be mentioned as a reference for
> not deprecating HMAC-SHA-1 as well as an
> additional reference to [NISTSP800-131A-R2]. 

Are asking for something like this:

OLD:

  In 2011, [RFC6151] detailed the security considerations,
  including collision attacks for MD5.

NEW:

  In 2011, [RFC6151] [RFC6194] detailed the security considerations,
  including collision attacks for MD5 and SHA-1, respectively.

> Reading the text the situation of HMAC with
> MD5 is unclear. Since we specify that SHA-1
> is not deprecated for HMAC we may specify
> the status for HMAC with MD5. Given RFC6151 I
> hope the reason is that MD5 and HMAC-MD5 has
> already been deprecated but I have not found
> this. Maybe that would worth mentioning it
> is deprecated already.
> 
> 

Are you asking for something like this:

OLD:

  However, this document does not deprecate SHA-1 in HMAC
  for record protection.

  However, this  document does not deprecate MD-5 or SHA-1 HMAC
  for record protection.

> [...]
> 
> 2.  Signature Algorithms
> 
>   Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
>   extension.  If a client does not send a signature_algorithms
>   extension, then the server MUST abort the handshake and send a
>   handshake_failure alert, except when digital signatures are not used
>   (for example, when using PSK ciphers).
> 
> 
> It seems to me that the server behavior might
> be defined as well. In our case this could be
> something around the lines the server MUST
> ignore MD5 and SHA1 values in the signature
> algorithm extension. 
> 
> 

I guess that would be the way to absolutely stamp them out, but don’t we get 
the same result because the client is not sending the values in the 
signaure_algorithms extension?

> 3.  Certificate Request
> 
>   Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest
>   messages.
> 
> 
> It seems to me that the same level of
> authentication should be provided for both
> peers and that server MUST NOT  include MD5
> or SHA-1.
> 
> A SHOULD NOT status might be welcome for a
> smooth transition. At that time, collision
> for MD5 and SHA1 are known for years. It is likely
> that software that still need MD5 or SHA1 are
> likely to never upgrade, so I doubt a smooth
> path worth being taken. 
> 

This has been a SHOULD NOT since it was a first published as an individual 
draft and through the WGLC. I would not feel comfortable changing it now 
without further discussion.

I tend to think it is okay to leave as SHOULD NOT because the server MUST use 
values from the now ever present signature_algorithms extension and MD5 and 
SHA1 are not going to be there. If the server is going to go nuts and include 
MD5 and SHA-1 in the CertifiateRequest even though it’s not been asked, well, 
you got bigger problems.

> 4.  Server Key Exchange
> 
>   Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
>   If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange
>   message it MUST abort the connection with

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Sean Turner]

> On Oct 27, 2020, at 10:32, Daniel Migault  wrote:
> 
> To address the comment below, keeping weak security is likely to weaken 
> current and future IoT communications, so I do not think there is room for 
> compromise with performance. Of course this is in a context of TLS.  I expect 
> protocol to leverage from TLS security, so the impact should be rather 
> negligible. 
> 
> """
> As those hash algorithms were 'cheap' for TLS 1.2, I would appreciate a 
> review of impacted IoT protocols if those algorithms are deprecated.
> """

In terms of process, are you suggesting "a review of impacted IoT protocols if 
those algorithms are deprecated” MUST be completed prior to advancing this 
document to the IESG?

spt

> Yours, 
> Daniel
> 
> 
> On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker 
>  wrote:
> Reviewer: Daniel Migault
> Review result: Ready with Nits
> 
> Hi,
> 
> 
> I reviewed this document as part of the IoT Directorate's ongoing effort to
> review all IETF documents being processed by the IESG.  These comments were
> written primarily for the benefit of the Security Area Directors.  Document
> authors, document editors, and WG chairs should treat these comments just like
> any other IETF Last Call comments.  
> 
> Review Results: Ready with Nits
> 
> Please find my comments below.
> 
> Yours,
> Daniel
> 
> 
>  Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
>   draft-ietf-tls-md5-sha1-deprecate-04
> [...]
> 
> 1.  Introduction
> 
>The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
>specified in [RFC5246].  MD5 and SHA-1 have been proven to be
>insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
>detailed the security considerations, including collision attacks for
>MD5.  NIST formally deprecated use of SHA-1 in 2011
>[NISTSP800-131A-R2] and disallowed its use for digital signatures at
>the end of 2013, based on both the Wang, et. al, attack and the
>potential for brute-force attack.  In 2016, researchers from INRIA
>identified a new class of transcript collision attacks on TLS (and
>other protocols) that rely on efficient collision-finding algorithms
>on the underlying hash constructions [Transcript-Collision].
>Further, in 2017, researchers from Google and CWI Amsterdam
>[SHA-1-Collision] proved SHA-1 collision attacks were practical.
>This document updates [RFC5246] and [RFC7525] in such a way that MD5
>and SHA-1 MUST NOT be used for digital signatures.  However, this
>document does not deprecate SHA-1 in HMAC for record protection.
> 
> 
> RFC6194 may be mentioned as a reference for
> not deprecating HMAC-SHA-1 as well as an
> additional reference to [NISTSP800-131A-R2]. 
> 
> Reading the text the situation of HMAC with
> MD5 is unclear. Since we specify that SHA-1
> is not deprecated for HMAC we may specify
> the status for HMAC with MD5. Given RFC6151 I
> hope the reason is that MD5 and HMAC-MD5 has
> already been deprecated but I have not found
> this. Maybe that would worth mentioning it
> is deprecated already.
> 
> 
> 
> [...]
> 
> 2.  Signature Algorithms
> 
>Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
>extension.  If a client does not send a signature_algorithms
>extension, then the server MUST abort the handshake and send a
>handshake_failure alert, except when digital signatures are not used
>(for example, when using PSK ciphers).
> 
> 
> It seems to me that the server behavior might
> be defined as well. In our case this could be
> something around the lines the server MUST
> ignore MD5 and SHA1 values in the signature
> algorithm extension. 
> 
> 
> 
> 3.  Certificate Request
> 
>Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest
>messages.
> 
> 
> It seems to me that the same level of
> authentication should be provided for both
> peers and that server MUST NOT  include MD5
> or SHA-1.
> 
> A SHOULD NOT status might be welcome for a
> smooth transition. At that time, collision
> for MD5 and SHA1 are known for years. It is likely
> that software that still need MD5 or SHA1 are
> likely to never upgrade, so I doubt a smooth
> path worth being taken. 
> 
> 
> 4.  Server Key Exchange
> 
>Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
>If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange
>message it MUST abort the connection with the illegal_parameter
>alert.
> 
> 
> As per section 2, the client has clearly
> indicated it does not support signature with
> MD5/SHA1, so Server Key Exchange should not
> end up with signature with SHA1/MD5. 
> 
> """
> If the client has offered the "signature_algorithms" extension, the
>signature algorithm and hash algorithm MUST be a pair listed in that
>extension. 
> """
> 
> It also seems to me that the constraint of
> including a MD5 and SHA-1 signature is
> related to the Certificate. I susp