[TLS] draft-ietf-tls-srp-13

[Trevor Perrin <trevp@xxxxxxxxx>]

A new TLS/SRP draft has been posted.

There are some significant changes in response to comments from Pasi and 
Eric, and to make this draft suitable as Experimental:
 - hello extension number marked IANA TBD
 - ciphersuite numbers marked IANA TBD
 - alert numbers changed to reuse existing alerts
 - the feature of optionally sending a 2nd ClientHello on same 
connection was removed, as it deviated from the RFC 4346 message exchange.
 - fair bit of text cleanup, in particular "Security Considerations" 
was re-structured, and considerations about Hash Function Agility were 
added.

The authors still need to decide how to handle the normative reference 
to SRP-6, which currently is just a URL.  There's several options, among 
them:
 - wait for IEEE P1363.2 to become a standard, reference that
 - move the reference to informational, since all necessary details are 
already in this document

Regardless, the authors invite feedback on the current state of the draft.


Trevor


Detailed Changelist 12->13
---------------------------
 - In 2.3, capitalized "SHALL"

 - In 2.5.1, add two clarifying sentences to end to define the phrase 
"SRP extension" and introduce the next two subsections.

 - In 2.5.1.1, replace phrase "user name extension" with "SRP 
extension" for clarity

 - In 2.5.1.2, rename title "Missing SRP Username" -> "Missing SRP 
Extension" for clarity

 - In 2.5.1.2, replace 'MAY return a "missing_srp_username"' with 
'SHOULD return a fatal "unknown_psk_identity"' to avoid defining a new 
alert.

 - In 2.5.1.2, replace "This alert signals the client to resend the 
hello message" with "A client receiving this alert MAY choose to 
reconnect and resend the hello message".  The old behavior of sending a 
2nd ClientHello on the same connection is removed.

 - In 2.5.1.2, delete last two paragraphs, same reason.

 - In 2.5.1.3, replace "the given user name" with "the user name in the 
SRP extension" for clarity.

 - In 2.5.1.3, replace "unknown_srp_username" with 
"unknown_psk_identity" to avoid defining a new alert.

 - In 2.5.3, replace "untrusted_srp_parameters" with 
"insufficient_security" to avoid defining a new alert.

 - In 2.7, change the CipherSuite numbers from {0x00, TBD} to {0xC0, 
TBD}, since the range with first byte < 0xC0 requires Standard Action 
for assignment.

 - In 2.8.1, change reference from 2.4 -> 2.3

 - In 2.9, replace the definition of 3 new alerts with a description of 
how the 4 old alerts in this draft are used.

 - In 3, break into subsections

 - In 3, move the consideration of checking A and B to the top and 
strengthen the language, since it's very important but I've seen several 
SRP implementations skip this.

 - In 3, replace "missing_srp_username" with "unknown_psk_identity", 
and remove some excess language.

 - In 3, remove mention of "locking" out an account, since redundant 
with prior suggestions, and potentially a security risk of its own.

 - In 3, reword discussion of attacker "learns a user's verifier"

 - In 3, add "Security Consideration" about hash functions

 - In 3, add reference to [TLS] for PRNG req'ts

 - In 4, update IANA considerations for hello extension - 6 is no 
longer suggested.

 - In 4, delete IANA considerations for alerts, since they require 
Standards Track

 - In 4, update IANA considerations for ciphersuites, to use the first 
byte 0xC0 per above.




_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls