hing should be
changed here to reflect that decision, but I thought it is worth
mentioning. It is possible that I'll follow boringssl's example in tris.
If a TLS extension is introduced later, hopefully that improves interop
with odd keys and signatures that are optional in this PR (PSS pubke
age, including the handshake message
header carrying the handshake message type and length fields, but not
including record layer headers
(The only way to know the message type is to have it in cleartext.)
--
Kind regards,
Peter Wu
https://lekensteyn.nl
_
g the
parameters as used for TLS handshakes to be supported (as the PR
proposes) and allowing alternative configurations to be supported too.
Kind regards,
Peter
> -Ekr
>
>
> On Tue, Nov 21, 2017 at 7:54 PM, Peter Wu wrote:
>
> > Hi,
> >
> > At the moment ther
Hi Nikos,
On Wed, Nov 22, 2017 at 09:42:04AM +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, 2017-11-22 at 03:54 +0000, Peter Wu wrote:
> > Hi,
> >
> > At the moment there is still ambiguity in the requirements for PSS
> > with
> > relation to certificates. Pr
.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
(terse) reference I could find is
https://www.ietf.org/mail-archive/web/tls/current/msg24517.html
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
shark 2.6 will have
support for TLS 1.3 (0x304) and close
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12779
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi,
In what way is the old writing ambiguous? The semantics of that text is
correct. If someone wants to run the TLS protocol on paper as
"transport", it would still maintain the same guarantees. And "paper" is
arguably not a transport protocol or "stream delivery service".
I suggest to reject th
Hi,
The original text was not wrong. Originally TLS 1.2 and before defined a
PRF for key derivation, and there exist multiple instantiations with
different hash functions (e.g. SHA-256 and SHA-384). So each
instantiation could be considered a different function.
Your suggested text can also be co
Hi,
Throughout the document, it is pretty clear what optionality refers to:
1. Introduction
[...]
- Authentication: The server side of the channel is always
authenticated; the client side is optionally authenticated.
and from the same Protocol Overview section, 2 pages later
The change is in "a list of symmetric cipher/HKDF hash pairs" and Ben
suggests changing "HKDF hash" to either "Hash algorithm" or "Hash
algorithm (to be used with HKDF)".
The hash is not just used for the HKDF, but also for Transcript-Hash, so
if this had to be changed, I would vote for "Hash algo
Hi Ben,
Do you have a specific sentence that caused confusion for you? Both
"out-of-band" and "external" can be used interchangeably. What is
unclear about https://tools.ietf.org/html/rfc8446#section-2.2 for
example?
If you are interested in use of external PSKs, I suggest following this
work: ht
There is no error here, clarifications such as these which can already
be correctly interpreted by a careful reader should probably not be
reported through the errata system.
>From https://www.rfc-editor.org/errata-definitions/
Type Name: Editorial
Description: "a spelling, grammar, punctuation, o
The current section describes what a client should do when it faces a
HRR, and the referenced bullet point specifies how the HRR "key_share"
extension should be processed.
The errata suggests "clarifying" that point by adding:
> Note: A "key_share" extension may not be supplied in a
> HelloRetryR
How could this affect the readers comprehension? This is not an
editorial issue in as defined at
https://www.rfc-editor.org/errata-definitions/
>From the context it is often clear what "abort" or "terminate" means.
An enumeration of the first occurrences in the document:
- "A failure of the hand
.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Mon, Aug 22, 2016 at 03:48:03PM +0300, Ilari Liusvaara wrote:
> On Mon, Aug 22, 2016 at 02:29:10PM +0200, Peter Wu wrote:
> > Hi,
> >
> > The Implementations wiki page in the Github repository
> > (https://github.com/tlswg/tls13-spec/wiki/Implementations) state
:
>
> https://www.wireshark.org/download/automated/
>
> THIS IS NOT THE PRODUCTION VERSION OF WIRESHARK!!!
>
> We owe HUGE thanks to Peter Wu & Alexis La Goutte (core Wireshark developers)
> for the TLS1.3 dissector. I did some minor, initial work on the dissector
> but it is
. Shouldn't the New Session Ticket Message
section be referenced instead?
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
1305.pcap
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
handshake messages, but what about certs?
What is needed for a TLS implementation to claim support for RSASSA-PSS?
In particular, for certificates:
- Limitations on salt length?
- What AlgorithmIdentifier OID to use?
- Whether to constrain other AlgorithmIdentifier Params? (MGF, hash
algorith
data is allowed in the same record following the Server Hello. And the
record after the Server Hello, there is an encrypted record containing
Encrypted Extensions (encrypted with the server handshake secret).
--
Kind regards,
Peter Wu
https://lekensteyn.nl
_
22 matches
Mail list logo
