Re: [Trans] IETF 90 scheduling

Ben Laurie <benl@google.com> Thu, 24 April 2014 14:52 UTC

Return-Path: <benl@google.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4DB1A033E for <trans@ietfa.amsl.com>; Thu, 24 Apr 2014 07:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cbpD7wnA91b for <trans@ietfa.amsl.com>; Thu, 24 Apr 2014 07:52:05 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9E10A1A032E for <trans@ietf.org>; Thu, 24 Apr 2014 07:52:05 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id il7so3125267vcb.32 for <trans@ietf.org>; Thu, 24 Apr 2014 07:51:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1Vtu4/rggeziTMbhnXZHB8fZACVVG531Gdcbs4Ea+ao=; b=Rusjyn56h979yMbnID2UkhTdfuHZ/uA+tNZD9MnqDLQl2JTGljN3IB8LQjPb0/rWe/ WMKN8BhivVftN+4wm2RQ8foCv6cZwnRlVjHV3evVuajefb18ng8ws8ZRyoRqrCWqySRl c1fnNW5CP6EchVOZyafgDfZR4JpsE8ommfefNVJWd/x2FZkS4lrXSIa1o0UjlG3yh9O4 rMDRyaUy+FUtCENttYYHOClOcgO5MyfZl2XvQ0HCGYZ8RQ0s7duipv73yWcRDecl0FVg Dj2D8238Lce8MsX7u60PKinyyQ9BHM4cDXy1rj8GjmVqINC274RqjrLFCRUdzqhFgrM7 OgjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1Vtu4/rggeziTMbhnXZHB8fZACVVG531Gdcbs4Ea+ao=; b=kv5JWPVORns6Z5wMl8wrf/1SzdEA+9ewiW1C/3VXawhsdjbHfNNPSf5SMImuOoRcc6 HWBbmSGPYs6FxqjotTDvCIk9iXRRaIuXu/H8r5VqaVXEzncwGiT74BaKqWG30pj0YGDl A17CM0zoPxsN9kcsVCM89zk75Hc1dUldXEtw6wy597dzNMWK6v9jqmfhlEgWh2FxbCgS LztVZvLi/GT2ekID9uTUBiU4NMqeN6Ieu2DZKCySj59J4OdSlBikAE4g5h+FQQ22gidg plKIGVzsWwy3eN+dNHgUO8bxWq8vuIVpMi2I1drnPlXok0xRA1u9ot0a9lhtGgVs0DhJ BAIw==
X-Gm-Message-State: ALoCoQnelzaglmxNb9fLBCMIB2P/CxZQnyEGLcHehSEbSeg08StTiksgfgC4R7I2G+/HT3A5EmmvBzXyY4xt1Sa8Zhmp1V37raiizAwnom7tcg5an19b4vECtkc/2GLOzwH4NL267k7a9Ss7FF/hhOHPpi0+8xHy8eig/4+NVxJQIby/eqFhf1PPDmYUrOeKFL9gjXS4Nj2x
MIME-Version: 1.0
X-Received: by 10.58.132.228 with SMTP id ox4mr666133veb.54.1398351119292; Thu, 24 Apr 2014 07:51:59 -0700 (PDT)
Received: by 10.52.119.179 with HTTP; Thu, 24 Apr 2014 07:51:59 -0700 (PDT)
In-Reply-To: <CAA7e52oXiCW4FfYfz-hT2=QOOm4xXGtxPmVwtC0rbcstQAP9qQ@mail.gmail.com>
References: <53559D3B.1090504@gmail.com> <CAA7e52oXiCW4FfYfz-hT2=QOOm4xXGtxPmVwtC0rbcstQAP9qQ@mail.gmail.com>
Date: Thu, 24 Apr 2014 15:51:59 +0100
Message-ID: <CABrd9SRA+TnYXPo0eoNMyMxvVRT8AV39QB2BGb1S1yJ8imx6xg@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Jean-Michel Combes <jeanmichel.combes@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b6da0eabcbc7d04f7cafd3c
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/h-NDjq2v7ZUQ4DdMvRrXyqxM0Tk
Cc: Melinda Shore <melinda.shore@gmail.com>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] IETF 90 scheduling
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Apr 2014 14:52:07 -0000

On 23 April 2014 15:51, Jean-Michel Combes <jeanmichel.combes@gmail.com>wrote;wrote:

> Hi,
>
> I have actually two technical comments with the current specifications of
> CT:
>
> #1 Log server identification
>
> Currently, if I am correct, the identity of the log server providing the
> SCT is based on its public key (in fact, the hash of it), which is also
> stored in the TLS client. As with the public key pinning mechanism (cf.
> draft-ietf-websec-key-pinning), I am afraid about a potential complexity
> (from a technical/business point of view) to add a new public key in the
> TLS client (e.g., web browser), to be able to set up/manage a new log
> server.
>
> So, I am wondering, instead (or in parallel) of using log server's public
> key as log server's ID, if that would be easier to use URI for new log
> servers deployment.
>

There's already been a fairly extensive discussion on this, perhaps still
not resolved. But my position continues to be that the TLS client needs to
know various things about the log - public key, URL, MMD. I don't see the
problem in those things being communicated in a data structure (e.g. in
JSON).

Indeed we will shortly be defining such a structure for Chrome's valid
logs. Whether this should form part of the RFC is up to the WG.


>
> #2 Interaction between TLSA RR and CT
>
> At first, from my point of view, using TLSA RR means "prevention" and
> using CT means "repression". Now, if I want only do "prevention", the
> current CT specifications will not allow me to do it. Indeed, as specified
> in Section 3, TLS clients MUST reject certificates that do not have a valid
> SCT for the end-entity certificate, enforcing the use of CT by the TLS
> server.
>

That is correct.


>
> Maybe, replacing the MUST by a SHOULD, when TLSA RR is deployed, would
> relax this enforcement.
>

No, because this gives an attacker a way to evade CT.

I would appreciate any feedback from the WG regarding these comments.
>
> Thanks in advance for your replies.
>
> Best regards,
>
> JMC.
>
>
> 2014-04-22 0:35 GMT+02:00 Melinda Shore <melinda.shore@gmail.com>om>:
>
> We just received notification that working group session
>> scheduling for the July meeting is now open.  This is a good
>> time to be thinking about what needs to be done between
>> now and then and how session time will be spent.  Right now
>> my sense is that a single two-hour session will be more than
>> enough, but I'll hold off until we get a better sense of
>> what will need to be done during the session.
>>
>> Melinda
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>


-- 
Certificate Transparency is hiring! Let me know if you're interested.